Using ETag Headers with Cloudflare

Learn how Cloudflare interacts with Entity Tag (ETag) headers set by your origin web server to ensure your resource versions cached in Cloudflare’s CDN match those cached in your visitor’s browser.


ETag headers identify whether the version of a resource cached in the browser is the same as the resource at the web server.  A visitor’s browser stores ETags. When a visitor revisits a site, the browser compares each ETag to the one it stored. Matching values cause a 304 Not-Modified HTTP response that indicates the cached resource version is current.   Cloudflare supports both strong and weak ETags configured at your origin web server.

Weak ETags

Weak ETag headers indicate a cached resource is semantically equivalent to the version on the web server but not necessarily byte-for-byte identical.   Cloudflare supports weak ETag headers on all plans.

When using weak ETag headers, disable Email Obfuscation and Automatic HTTPS Rewrites to ensure Cloudflare doesn't remove the ETag headers set by your origin web server.

Strong ETags

Strong ETag headers ensure the resource in browser cache and on the web server are byte-for-byte identical.  Domains on Enterprise plans enable strong ETag headers via a Respect Strong ETags Page Rule.  Otherwise, strong ETag headers are converted to weak ETag headers. Also, set a strong ETag header in quotes (Etag: "example") or Cloudflare removes the ETag instead of converting it to a weak ETag. 

Without a Page Rule, Cloudflare preserves strong ETags set by the origin web server if:

Enabling Strong ETags via Cloudflare automatically disables Rocket Loader, Minification, Email Obfuscation, and Railgun.

If a resource is cacheable and there is a cache miss, Cloudflare does not send ETag headers to the origin. This is because Cloudflare requires the full response body to fill its cache.

Related resources

Not finding what you need?

95% of questions can be answered using the search tool. This is the quickest way to get a response.