Broadly speaking, this allows a server to distinguish between: requests originating from a user navigating between HTML pages, and requests to load images and other resources. For example, this header would contain
navigate for top level navigation requests, while
no-cors is used for loading an image.
|Header type||Fetch Metadata Request Header|
|Forbidden header name||yes (prefix
|CORS-safelisted request header||no|
Sec-Fetch-Mode: cors Sec-Fetch-Mode: navigate Sec-Fetch-Mode: no-cors Sec-Fetch-Mode: same-origin Sec-Fetch-Mode: websocket
Servers should ignore this header if it contains any other value.
These directives correspond to the values in
- The request is a CORS protocol request.
- The request is initiated by navigation between HTML documents.
- The request is a no-cors request (see
- The request is made from the same origin as the resource that is being requested.
- The request is being made to establish a WebSocket connection.
If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers (note that the mode is
Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: same-origin Sec-Fetch-User: ?1
A cross-site request generated by an
<img> element would result in a request with the following HTTP request headers (note that the mode is
Sec-Fetch-Dest: image Sec-Fetch-Mode: no-cors Sec-Fetch-Site: cross-site
|Fetch Metadata Request Headers (Fetch Metadata)|
BCD tables only load in the browser
- Related headers
- Protect your resources from web attacks with Fetch Metadata (web.dev)
- Fetch Metadata Request Headers playground (secmetadata.appspot.com)