Web Tools
Cache-Control Header Builder
Build and understand HTTP Cache-Control directives.
Generated header value
public, max-age=3600This builder generates a header value and points out a few contradictory combinations. It cannot know your application’s content lifecycle, CDN behavior, authentication model, or framework defaults, so review the result before production use.
About This Tool
HTTP caching can make repeat visits faster and reduce unnecessary origin work, but a Cache-Control header needs to match how long a response is safe to reuse and whether shared caches may store it. This builder combines common response directives into one copyable header value and highlights several combinations that deserve review. It does not send a request or change server configuration.
How To Use It
- Choose whether the response may be stored by shared caches (public), is intended for a private cache (private), or needs no explicit visibility directive.
- Enable behavioral directives such as no-store, no-cache, must-revalidate, or immutable only when they match the response lifecycle.
- Enter optional freshness or stale windows in whole seconds. Blank fields are omitted from the header.
- Review any conflict warnings, then copy the generated Cache-Control header into the appropriate server, framework, CDN, or hosting configuration.
Examples
Short browser freshness
public, max-age=3600 allows a stored response to remain fresh for 3,600 seconds (one hour), subject to the cache and response being otherwise cacheable.
Shared-cache override
public, max-age=60, s-maxage=600 gives private caches a 60-second freshness lifetime while s-maxage provides a 600-second freshness lifetime for shared caches that support it.
Revalidate before reuse
no-cache does not mean “do not store.” It means a stored response must be successfully validated with the origin before it is reused.
Do not store
no-store tells caches not to store the response. Combining it with long freshness or stale-reuse directives is contradictory, so this builder warns about that mix.
Useful Notes
max-age and s-maxage
max-age defines a freshness lifetime in seconds. s-maxage applies to shared caches and, when applicable, takes precedence over max-age for those caches. Browser/private caches still use the directives relevant to them.
no-cache versus no-store
The names are easy to confuse. no-cache permits storage but requires validation before reuse. no-store instructs caches not to store the response. Choose based on the response's sensitivity and reuse requirements rather than treating them as interchangeable.
public and private
private indicates that a response is intended for a private cache and must not be stored by a shared cache. public explicitly permits shared-cache storage when the response is otherwise cacheable. Whether public is necessary depends on the response and surrounding HTTP semantics.
Revalidation and immutable responses
must-revalidate controls reuse after a response becomes stale. immutable indicates that a fresh response will not change during its freshness lifetime, which can reduce unnecessary revalidation. Versioned static assets are a common immutable use case when their URLs change whenever content changes.
Serving stale responses
stale-while-revalidate allows supported caches to reuse a stale response for a specified period while revalidating it in the background. stale-if-error allows supported caches to reuse stale content for a specified period when an error occurs. Support and behavior can vary across caches and intermediaries.
Configuration context still matters
A syntactically plausible header can still be wrong for a particular application. Authentication, cookies, personalized responses, CDN rules, framework defaults, validators such as ETag, and content update frequency all affect a sound caching policy. This tool generates directives; it does not audit deployment behavior.
FAQ
What unit do max-age and s-maxage use?
Seconds. For example, 60 is one minute, 3600 is one hour, and 86400 is one day.
Does no-cache disable caching?
No. It allows a cache to store the response but requires successful validation before reuse. Use no-store when the intention is to instruct caches not to store the response.
Should I use immutable on every static file?
No. It is most appropriate when a fresh resource truly will not change during its freshness lifetime, commonly when filenames or URLs are content-versioned. Using it on a resource that changes at the same URL can keep stale content fresh longer than intended.
Why does the builder warn about private with s-maxage?
private prevents shared caches from storing the response, while s-maxage defines freshness for shared caches. Combining them usually signals conflicting intent.
Does this test my CDN or server?
No. It only builds a header value locally. Verify the actual response headers and caching behavior in your deployment because servers, frameworks, CDNs, and proxies can add, override, or interpret caching configuration.
Related Tools
Heading Hierarchy Checker
Inspect an HTML heading outline and spot skipped levels.
URL Parser & Inspector
Inspect URL components and query parameters.
Query String Builder
Build encoded URL query strings from key-value parameters.
Color Contrast Checker
Check WCAG text contrast ratios for two web colors.