Skip to content
Docs

Response headers

The following headers are included in Vercel deployment responses and indicate certain factors of the environment. These headers can be viewed from the Browser's Dev Tools or using an HTTP client such as curl -I <DEPLOYMENT_URL>.

Used to specify directives for caching mechanisms in both the CDN cache and the browser cache. See the Cache-Control headers section for more detail.

If you use this header to instruct the CDN to cache data, such as with the s-maxage directive, Vercel returns the following cache-control header to the client:

-cache-control: public, max-age=0, must-revalidate

An integer that indicates the number of bytes in the response.

The media type that describes the nature and format of the response.

A timestamp indicating when the response was generated.

Shows where the request came from. This header can be overridden by other proxies (e.g., Cloudflare).

A header often abbreviated as HSTS that tells browsers that the resource should only be requested over HTTPS. The default value is strict-transport-security: max-age=63072000 (2 years)

Present only on:

We add this header automatically with a value of noindex to prevent search engines from crawling your Preview Deployments and outdated Production Deployments, which could cause them to penalize your site for duplicate content.

You can prevent this header from being added to your Preview Deployment by:

The x-vercel-cache header indicates the cache status of static assets and responses from Vercel's CDN. For dynamic routes and fetch requests that use the runtime cache, this header often shows MISS even if the data is served from the runtime cache. Use custom headers or runtime logs to check whether a fetch response was served from the runtime cache.

The header returns one of the following values. For what each one means in depth, including the reasons behind a miss, bypass, or stale response, see Cache Status and Reasons:

  • HIT: the response was served from the cache.
  • MISS: the response wasn't in the cache and was generated from your function or origin.
  • STALE: a cached response was served while Vercel refreshed it in the background.
  • PRERENDER: the response was served from static storage.
  • REVALIDATED: the response was regenerated in the foreground after the cached entry was deleted.
  • BYPASS: Vercel skipped the cache and served fresh content from your function or origin.

This header contains a list of Vercel regions your request hit, as well as the region the function was executed in (for both Edge and Serverless).

It also allows Vercel to automatically prevent infinite loops.

Last updated July 1, 2026

Was this helpful?

supported.