publicAllows shared storage when the other caching requirements are met.
Line 1, column 16
HTTP & Request Debugging
Cache-Control generatorunderstand each cache decision
Parse a response header or build one with directive fields. Compare freshness using an assumed current age.
Cache-Control generator
Headers and form values stay in this browser. No origin requests are sent.
Browser / private cache
Fresh in this age example
max-age: 3600 seconds lifetime
Freshness budget remaining: 3600 seconds
Shared cache / CDN
Fresh in this age example
s-maxage: 86400 seconds lifetime
Freshness budget remaining: 86400 seconds
Once stale, revalidate before reuse under these directives.
Assumes an already stored response and the age supplied below. Freshness does not guarantee storage or reuse; other headers and platform rules still apply.
Use an assumed current_age from 0 to 2147483648. An Age header alone does not include all transit and residence time; this is a static example.
Parsed directives
max-age=3600Freshness lifetime for private caches and shared caches without s-maxage.
Line 1, column 24
s-maxage=86400Overrides max-age for shared caches; not for browsers.
Line 1, column 38
Showing 3 of 3 directives
Policy notes
No issues detected in the modeled directives. This does not verify deployment.
3 directives · 0 policy notes
A CDN can keep a response longer than a browser without changing the resource itself. The Cache-Control generator helps you inspect that split when a page seems fresh at one layer and stale at another. Begin with the supplied example, then substitute your own header.
This Cache-Control header builder also parses existing HTTP caching headers. It keeps uncommon extensions visible, so reviewing an unfamiliar policy does not start by reducing it to the few switches a form understands.
Why use this Cache-Control generator
Keep investigation separate from construction
The Cache-Control generator preserves the parser input when you switch to the form. A quoted field list or repeated directive remains available for inspection. Building a new policy does not overwrite that evidence, and normalization never silently removes conflicts.
Compare two freshness budgets
With max-age=3600 and s-maxage=86400, the two caches use different lifetimes. Set the assumed current age to 4000 seconds: the browser example is stale, while the shared example has 82400 seconds left. Those figures describe freshness, not a promised cache hit.
Read the source before choosing a lifetime
01
Choose the input format
Paste a bare value or one or more Cache-Control field lines. A full response block containing Age or ETag is rejected rather than partially ignored. Quoted commas remain inside their argument.
02
Treat zero as a deliberate setting
In the form, an empty time field omits the directive; 0 emits an explicit zero. Switching modes retains both inputs. Loading the example or clearing first previews replacement and allows one undo.
03
Adjust the age assumption
The age field is an assumed current response age in seconds, not a clock or a fetched Age header. Automatic runs wait 350 ms; turn them off for the button or Ctrl/Cmd + Enter. Any edit disables old exports immediately.
Inspect directives and their consequences
Parse without losing diagnostic clues
Names are case-insensitive and the output uses lowercase names. Arguments, quoted spelling, order and repeated entries stay visible. Empty comma members are skipped. Each row includes a source position, making multi-line headers easier to review.
Build common response directives
Combine nine switches with max-age, s-maxage, stale-while-revalidate and stale-if-error. Time inputs accept whole seconds from 0 to 2147483648. Incompatible choices remain visible with diagnostics; the form does not decide your policy by deleting them.
Distinguish freshness from reuse
The max-age vs s-maxage comparison separates browser and shared cache lifetimes. no-cache requires validation before reuse; no-store prohibits storage under its ordinary semantics. A positive lifetime alone does not establish that a response can be stored or served.
Explain policies that need more context
Unknown extensions, field-qualified restrictions and must-understand receive conditional explanations. Repeated known directives or invalid arguments suppress numeric conclusions. Copy and text download contain the complete current header, even when the list displays only 50 rows.
What one response header can tell you
- Response headers only
- This page does not issue requests, inspect a URL, simulate request directives or evaluate ETag, Vary and Expires together. Request-only directives are retained with a scope note. Server configuration snippets and batch files are outside its scope.
- A calculated example, not an expiry timestamp
- The lifetime minus assumed current age calculation omits Date correction, transit time and residence time. Without max-age or s-maxage, the relevant lifetime is unspecified: Expires or heuristic freshness may still exist elsewhere.
- No vendor validation
- CDN rules, authorization, response status and cache keys affect actual behavior. A clean diagnostic list is not a deployment approval. The tool neither purges caches nor guarantees cache hits, storage or identical behavior across browsers.
- Finite input and conservative ambiguity
- Input is limited to 16384 UTF-16 units and 128 directives. Syntax errors stop export and show a position. Oversized parsed delta-seconds are preserved with a range note and no numeric inference; generated seconds and assumed age are capped at 2147483648.
- Stale allowances do not extend freshness
- stale-while-revalidate and stale-if-error describe conditional reuse after freshness ends. The tool explains them without adding them to the fresh lifetime or promising stale delivery. Restrictive revalidation directives are flagged for review.
Cache-Control generator questions
How do no-cache and no-store differ?
The no-cache vs no-store distinction is about reuse versus storage. Ordinary no-cache allows storage but requires successful validation before another reuse. Ordinary no-store prohibits storing the response. Neither is a command to erase every previously cached copy.
How should I choose a max-age value?
Choose a lifetime based on how long the resource may remain unchanged for clients. Versioned assets and frequently changing pages have different needs. The default hour/day pair is a comparison example, not a recommendation for your endpoint; test the deployed response afterward.
What does immutable change?
immutable indicates that the representation will not change while it is fresh. It does not create a lifetime, prevent every forced reload or remove validation after staleness. Its arguments are ignored and repeated instances are equivalent to one under RFC 8246.
How does s-maxage differ from max-age?
max-age applies to private caches and to shared caches without an overriding s-maxage. s-maxage supplies the shared-cache lifetime and requires revalidation once stale. It does not lengthen the browser lifetime.
Can a header builder verify the policy against my origin?
No. This page constructs and inspects text only. To verify deployment, inspect the real response and the platform's cache configuration. A vendor override or another response header can change behavior even when the generated Cache-Control string is syntactically valid.
Something looks wrong?
Review a policy before deploying it
Cache-Control generator: inspect your header, adjust the age assumption and compare both cache lifetimes before copying.