Cache-Control Header Builder

Build Cache-Control headers with a visual form. Toggle directives, set durations, and export ready-to-use server configuration snippets.

About This Tool

The Cache-Control Header Builder is a free, browser-based tool that helps developers construct Cache-Control HTTP response headers without memorizing the specification. Cache-Control is the primary mechanism for controlling how browsers, CDNs, and proxy caches store and serve responses. A well-tuned caching strategy dramatically reduces server load, lowers bandwidth costs, and accelerates page load times for end users.

Despite its importance, writing a Cache-Control header by hand is surprisingly tricky. Directives interact with each other in subtle ways — for example, no-cache does not mean "never cache" (that would be no-store), and max-age=0, must-revalidate behaves differently from no-cache in edge cases involving stale content. This tool eliminates confusion by providing toggle switches for every directive, duration presets for time-based values, and a real-time visual timeline that shows how the browser and CDN will treat the cached response over time.

The builder covers all standard Cache-Control directives: public, private, no-cache, no-store, max-age, s-maxage, must-revalidate, proxy-revalidate, no-transform, immutable, stale-while-revalidate, and stale-if-error. Five one-click presets — Static Assets, API Responses, HTML Pages, Private User Data, and No Caching — give you a sensible starting point that you can customize to match your exact requirements.

All processing happens entirely in your browser using client-side JavaScript. No data is sent to any server, so you can safely experiment with caching configurations for internal or production systems. Once your header is ready, verify its effect alongside other response headers with the HTTP Header Analyzer, or generate the accompanying security headers with the CSP Header Generator. For complete HTML metadata, the Meta Tag Generator can help you set cache-related meta tags as well.

How to Use

  1. Click one of the preset buttons (Static Assets, API Responses, HTML Pages, Private User Data, No Caching) for a quick starting point, or begin from scratch.
  2. Toggle individual directives on or off using the switches in each section: Cacheability, Expiration, Revalidation, Other, and Stale Content.
  3. For time-based directives (max-age, s-maxage, stale-while-revalidate, stale-if-error), click a duration preset (1m, 1h, 1d, 1w, 1y) or type a custom value in seconds.
  4. Review the generated Cache-Control Header on the right. The full Cache-Control: ... string updates in real time.
  5. Check the Cache Behavior Timeline to visualize the fresh, stale-while-revalidate, and stale-if-error phases.
  6. Switch between Nginx, Apache, and Express.js tabs to get a ready-to-paste server configuration snippet.
  7. Click Copy Header (or press Ctrl+Shift+C) to copy the output to your clipboard.

FAQ

What is the Cache-Control header?

Cache-Control is an HTTP response header that instructs browsers, CDNs, and proxy caches on how to store and serve a response. It controls whether a response can be cached, how long it stays fresh, and what happens when it becomes stale. It is the most important header for HTTP caching.

What is the difference between no-cache and no-store?

no-cache means the cache CAN store the response, but must revalidate with the origin server (using ETag or Last-Modified) before serving it. no-store means no cache should store any part of the response at all. If you want to completely prevent caching, use no-store. If you want to ensure freshness on every request while still benefiting from conditional requests (304 Not Modified), use no-cache.

What is s-maxage and when should I use it?

s-maxage (shared max-age) overrides max-age for shared caches like CDNs and reverse proxies, while the browser still uses max-age for its local cache. This is useful when you want a short browser cache (e.g., max-age=60) but a longer CDN cache (e.g., s-maxage=3600), allowing the CDN to serve content for an hour while the browser checks for updates every minute.

What does the immutable directive do?

The immutable directive tells the browser that the response body will never change during its freshness lifetime. This means the browser will not send conditional revalidation requests (If-None-Match / If-Modified-Since) even when the user explicitly reloads the page. It is ideal for versioned static assets (e.g., app.a1b2c3.js) that use content-hash filenames.

How does stale-while-revalidate improve performance?

stale-while-revalidate allows the cache to immediately serve a stale response while asynchronously fetching a fresh copy from the origin in the background. The user gets an instant response (even if slightly outdated), and subsequent requests get the updated version. This dramatically improves perceived performance for content that does not need to be perfectly fresh on every request.

Is my data safe?

Yes. All header generation happens entirely in your browser using client-side JavaScript. No data — including directive selections, duration values, or the generated header — is ever transmitted to a server. You can safely experiment with caching configurations for production systems without any privacy concerns.

Should I use public or private?

Use 'public' when the response is the same for all users and can be cached by CDNs and shared proxies (e.g., static assets, public API data). Use 'private' when the response contains user-specific data that should only be cached in the user's browser (e.g., personalized pages, authenticated API responses). If neither is specified, responses are typically treated as private by default for requests with Authorization headers.

Related Tools