Browser Cache TTL vs Edge Cache TTL in Cloudflare

Two independent TTLs

Cloudflare runs two separate expiry controls with confusingly similar names. The Edge Cache TTL decides how long a response is held in Cloudflare's data centers. The Browser Cache TTL decides how long the response is cached in each visitor's browser, the machine the browser runs on. They are set independently, and understanding which is which is the difference between "the cache is configured" and "the cache is actually configured correctly".

The edge TTL and caching rules control the middle layer, the layer you can purge. The browser TTL controls the far layer, the layer you cannot reach. Once a visitor's browser stores an asset, no purge request from your Cloudflare dashboard can evict it; the browser only drops or revalidates it when its own max-age elapses.

How the default really behaves

The default Browser Cache TTL is 4 hours on every plan tier (Free, Pro, Business and Enterprise). That default surprises people because a year-long Cache-Control: max-age=31536000 they set at the origin shows up in the browser as 4 hours. This is not a bug: Cloudflare honors the origin's Expires and Cache-Control only when interpreting the browser cache, but it overrides those headers when either of two conditions holds:

• The origin's Expires or Cache-Control value is lower than the Browser Cache TTL you configured, or
• The origin sends no Cache-Control or Expires header at all.

The mechanism Cloudflare uses changes depending on where you configure it. A cache rule sets the Browser Cache TTL as an explicit value. The "Respect Existing Headers" choice, by contrast, leaves the origin's Cache-Control untouched and simply does not force a Cloudflare override. Because a visitor's browser obeys whatever Cache-Control arrives, rewriting it (a Cache Rule) or leaving it alone (Response Header Transform) produce genuinely different behaviour in the browser even though the edge cache is unchanged.

Practical read on the two defaults

The edge cache can be aggressive because you can purge it. The browser cache should be conservative because you cannot. Concretely:

• HTML pages: short browser TTL. Even after you purge the edge, a visitor whose browser is holding an old HTML copy with a long max-age will keep seeing it until that copy expires. Keep HTML browser TTL short, a few minutes, so a purge has a real effect.
• Fingerprinted static assets: long browser TTL. Files named with a content hash (app.a1b2c3.css) never collide with a newer version, so a long browser max-age is safe and fast.
• Purging is edge-only. After Caching > Configuration > Purge Cache, the edge is cold, but every browser that already holds the old asset keeps it until its own TTL passes. That is the mechanic behind the browser showing old content failure mode.

Set and verify

To raise or lower the setting, open Caching > Configuration, and under Browser Cache TTL choose a value. The minimum is 1 second on every current tier (older Page Rules allowed a 2 minute minimum on lower plans; a 30 second minimum on Enterprise). Use a cache rule to target specific paths instead of the zone-wide value when only part of the site needs a long browser cache.

Verify in DevTools: load the asset, open the Network tab, and read the Cache-Control header on the response. If it shows max-age=14400 where you wrote a year, the zone-wide Browser Cache TTL is overriding it. Add a cache rule that respects the origin header for that path, or lower the zone default. Pair this with the general HTTP caching basics to reason about the full chain from origin to edge to browser.