Set response headers with a _headers file in your site

Put a file named _headers at the root of your site’s build and the edge adds the headers it lists to matching responses. It’s the format Netlify and Cloudflare Pages use:

/*
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin

/assets/*
  Cache-Control: public, max-age=31536000, immutable

Unlike _redirects, where the first matching rule wins, every matching rule applies.

A Content-Security-Policy works without breaking the page. The edge adds a small script to every HTML page it serves. If your policy would block it, the edge adds that script’s hash to your policy, so it runs and nothing else inline does.

_headers and _redirects are no longer downloadable. Until now, a visitor could fetch either file from your site. Both now return a 404, whether or not they exist.

Limits

• Level 0 and Level 2 sites, not Level 1. The edge never receives a Level 1 key, so it can’t read _headers inside the site; that’s the point of Level 1. At Level 2 the headers apply once a visitor’s access token has been checked.
• Cache-Control can’t be loosened on an encrypted site. At Level 1 and Level 2 the edge’s no-cache wins, so decrypted content isn’t stored by shared caches. Every other header you set applies at Level 2.
• 100 rules per file, and 8 KiB of your headers per response.
• Some headers are the edge’s own and are dropped from _headers: those it sets for range requests, caching validation and redirects, such as Content-Range, ETag and Location. 23 in total.
• Under a restrictive policy, peer delivery hints are left out of the page, so its content comes from the gateway.