Headers and Basic Authentication
You can configure custom headers and basic auth for your Netlify site by adding a
_headers file to the root of your site folder.
Note that if you’re running a build command or site generator, the
_headers file should end up in the folder you’re deploying. Some generators, like Jekyll, may also require additional configuration to avoid exclusion of files that begin with
_. (For Jekyll, this requires adding an
include parameter to
The format is very simple. You can specify one or several URL paths with their additional headers:
## A path: /templates/index.html # Headers for that path: X-Frame-Options: DENY X-XSS-Protection: 1; mode=block /templates/index2.html X-Frame-Options: SAMEORIGIN
Paths can contain
:placeholder matches anything except
/ while a
* matches anything.
Here’s an example of settings the
X-XSS-Protection headers for all pages on your site:
/* X-Frame-Options: DENY X-XSS-Protection: 1; mode=block
If you have a Team plan, the headers file can also be used to set basic authentication headers. It’s a simple way to limit access to particular parts of your site.
/something/* Basic-Auth: someuser:somepassword anotheruser:anotherpassword
This will trigger the built-in basic browser authentication for any URL under
/something. There’s two users defined here, one with the username “someuser” and password “somepassword”, the other with “anotheruser” and “anotherpassword”.
Unlike other headers in the
_headers file, the
Basic-Auth header will obviously not be sent as a standard HTTP header but used to control the appropriate HTTP headers for basic authentication.
Basic-Auth is only available if you’re on a Teams Pro plan or higher.
If Visitor Access Control is also enabled, the Visitor Access Control password will be asked for after the Basic-Auth login prompt.
Multi-key header rules
_headers file can include multiple headers with the same name. In that case, Netlify, will concatenate the values of those headers into a single header as described in the RFC 7230.
For example, you can include several Link header fields in the file, like this:
/* Link: </style.css>; rel=preload; as=style Link: </main.js>; rel=preload; as=script Link: </image.jpg>; rel=preload; as=image
And they will be collapsed into one header following the HTTP 1.1 specification:
Link: </style.css>; rel=preload; as=style, </main.js>; rel=preload; as=script, </image.jpg>; rel=preload; as=image
You can also specify header rules in your
netlify.toml file. You can create this file in the base directory of your git repository, if you don’t have one already. We use TOML’s array of tables to specify each individual header rule. You can see the list of valid keywords for each rule below:
for: The path or URL where the headers will be added.
values: A map of values to add to the response headers.
You can see a full example here:
[[headers]] for = "/*" [headers.values] X-Frame-Options = "DENY" X-XSS-Protection = "1; mode=block" # COMMENT: Multi-key header rules are expressed with multi-line strings Link = </style1.css>; rel=preload; as=style, \ </style2.css>; rel=preload; as=style, \ </style3.css>; rel=preload; as=style
Testing header rules
You can test if the rules in your
_headers file are correct at Netlify’s Playground. Copy your rules there and click
Test rules. The playground will list all the invalid rules in your file if there are any.
If your rules are valid, they are automatically translated to the structured format, so you can easily migrate from one format to another.
Notice something is incorrect or outdated?
First off, great eye! We appreciate your discovery and want to ensure it gets addressed immediately. Please let us know here.