An HTTP Cache-Control header builder lets you configure browser and CDN caching rules without memorizing directive names. Choosing the right caching strategy can reduce server load by over 80% and dramatically improve page load times — especially for returning visitors. This tool generates the complete Cache-Control header value and ready-to-paste server configuration snippets.
Resource Type
Caching Strategy
max-age
Directives
Cache variations (e.g. Accept-Encoding for compression)
Cache-Control Header
Active Directives
Server Snippet
How to Build the Right Cache-Control Headers
Cache-Control headers tell browsers, CDNs, and reverse proxies how to store and reuse HTTP responses. Getting caching right is one of the highest-impact performance optimizations you can make — cached assets can load 100x faster than network requests. This HTTP cache header builder guides you through choosing the right directives for each type of resource.
Step 1: Choose Your Resource Type
Different resource types have different caching requirements. HTML pages are usually dynamic and should use short or no-cache strategies. CSS and JavaScript assets bundled with content hashes in their filenames (like main.a1b2c3.js) can be cached indefinitely as immutable. Images and fonts that rarely change can use long-term caching of 30 days to 1 year. Private user data must use the private directive to prevent CDN caching.
Step 2: Set max-age
The max-age directive specifies how many seconds a response can be served from cache before it's considered stale. Common values: 0 (no caching), 300 (5 minutes, for frequently updated content), 3600 (1 hour), 86400 (1 day), 2592000 (30 days), 31536000 (1 year, for immutable assets). After max-age expires, the browser must either revalidate with the server or fetch a fresh copy — depending on other directives.
Step 3: Add Key Directives
Beyond max-age, these directives shape caching behavior: public allows CDNs and shared caches to store the response — essential for assets that don't vary per user. private restricts caching to the end user's browser only. immutable tells browsers the content will never change, preventing conditional requests even on force-refresh. stale-while-revalidate lets browsers serve stale responses immediately while refreshing in the background — great for improving perceived performance. must-revalidate requires strict expiry checking — useful when stale data would cause significant problems.
Step 4: Configure the Vary Header
The Vary header tells caches that the response differs based on certain request headers. Vary: Accept-Encoding is the most common — it ensures separate cached copies exist for gzip and non-gzip responses. Vary: Accept-Language is used when serving localized content. Avoid too many Vary values as they fragment the cache and reduce hit rates.
Step 5: Copy the Server Snippet
Switch between the nginx, Apache, CDN, and Express.js tabs to get a configuration snippet formatted for your server. For nginx, the snippet sets headers inside a location block matching your file types. For Apache, it uses mod_headers directives. For Cloudflare CDN, it shows Page Rule or Cache Rules configuration. For Express.js, it shows how to set headers programmatically per route or middleware.
Frequently Asked Questions
What is Cache-Control and why does it matter?
Cache-Control is an HTTP header that tells browsers and intermediaries (CDNs, proxies) how to cache a response. It directly affects page load speed — cached assets load from disk/memory in milliseconds instead of fetching from the network. Correct caching can reduce server load by 80% or more and dramatically improve Core Web Vitals scores like LCP and FID.
What is the difference between no-cache and no-store?
They sound similar but behave differently. 'no-store' means never cache the response anywhere — it must always be fetched fresh from the server. 'no-cache' means the response can be cached, but the browser must revalidate with the server (using ETag or Last-Modified) before using the cached copy. Use no-store for sensitive data like banking pages, and no-cache for dynamic content that changes frequently.
What does the 'immutable' directive do?
The 'immutable' directive tells browsers that a cached response will never change for its max-age period, so they should never send revalidation requests even if the user force-refreshes. This is ideal for content-addressed static assets like JavaScript bundles with hash filenames (e.g., main.a1b2c3.js). Immutable significantly reduces unnecessary conditional requests on page reload.
What is stale-while-revalidate?
stale-while-revalidate allows a browser or CDN to serve a stale (expired) cached response while simultaneously fetching a fresh copy in the background. This delivers near-instant page loads on repeat visits while keeping content fresh. For example, Cache-Control: max-age=3600, stale-while-revalidate=86400 means serve cached for 1 hour, but if stale serve from cache for up to 24 hours while refreshing.
What is the difference between public and private caching?
'public' means any cache (browser, CDN, proxy) can store the response. 'private' means only the end user's browser can cache it — CDNs and shared proxies must not cache it. Use 'private' for personalized content like user dashboards and account pages. Use 'public' for shared assets like images, CSS, and JavaScript that are the same for all users.
Is this cache header builder free?
Yes, completely free. All header generation happens in your browser — no data is sent to any server. Generate as many configurations as you need with no account or signup required.
How do ETags work with Cache-Control?
An ETag is a fingerprint (hash) of the response content. When a cached response expires, the browser sends a conditional request with the ETag. If the content hasn't changed, the server returns a 304 Not Modified response with no body — saving bandwidth. ETags work alongside Cache-Control's max-age: when max-age expires, the ETag validates whether a fresh download is needed.