Cache-Control Header Builder – Cache Directives | NetworkUstad

Caching decides whether a visitor sees your latest page or last week version, and the Cache-Control header is where that decision is written. A wrong value either serves stale content for hours or forces every visitor to re-download everything, hurting both freshness and speed. The header is a comma-separated list of directives, and each has a precise meaning: max-age sets lifetime in seconds, public and private decide who may cache, no-store forbids caching entirely, and must-revalidate forbids serving stale copies. This builder assembles a correct header from your choices, so you can paste it into a server configuration with confidence.

How to Use the Cache-Control Header Builder

1. Choose public for shared caches or private for a single user.
2. Enter max-age in seconds, such as 3600 for one hour.
3. Optionally set s-maxage for shared caches.
4. Tick must-revalidate if stale copies must never be served.
5. Click Build Header.
6. Paste the value into your server config and test with a fresh and a repeat visit.

Key Features

• Supports public, private, no-cache, and no-store.
• Handles max-age and s-maxage in seconds.
• Adds must-revalidate, proxy-revalidate, and no-transform.
• Prevents contradictory combinations such as no-store with max-age.
• Produces a single paste-ready header value.
• Runs entirely in the browser; nothing is deployed automatically.

What the Result Means

The header is read by browsers and intermediate caches alike. Public means shared caches may store the response, private means only the end user browser may, and no-store means nobody may store it, which is right for sensitive pages. Max-age is the freshness lifetime: within it, the cached copy is used without contacting the server, and after it, the cache revalidates. Must-revalidate strengthens that: once stale, the cache must check with the server instead of serving the old copy during an outage, which trades availability for freshness.

Worked Example

A public article page that changes at most hourly needs shared caching for speed without staleness. Choosing public, max-age 3600, and must-revalidate produces: public, max-age=3600, must-revalidate. Browsers and CDNs serve the cached article for an hour, then revalidate, so readers see fresh content within the hour while the origin handles far fewer requests, since most repeat visits never reach it at all. A checkout page, by contrast, would use no-store, since its content must never be cached anywhere.

Best Practices and Tips

• Use long max-age values for versioned assets that never change, such as hashed files.
• Use short max-age or no-cache for pages that change often, such as news homepages.
• Never cache authenticated or personal pages as public.
• Test with developer tools open and cache disabled, then with it enabled, to see both paths.
• Remember that a long max-age on a changed file needs a new filename or a purge.

Common Mistakes to Avoid

• Setting no-store and max-age together, which contradict each other.
• Caching personal pages as public, leaking one user data to another.
• Using a long max-age on files whose names do not change with content.
• Forgetting s-maxage, so shared caches use a different lifetime than intended.

Frequently Asked Questions

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

No-cache allows storage but requires revalidation before reuse; no-store forbids storage entirely.

What does max-age count?

Seconds of freshness from the moment the response is received.

Should HTML pages have a long max-age?

Usually not, unless the filename changes with each deploy; HTML is the entry point that references everything else.

What is s-maxage?

A max-age that applies only to shared caches, overriding max-age for them while browsers use max-age.

Related Tools

• .htaccess Redirect Generator – Build Apache redirect rules
• Content Security Policy Builder – Build a Content-Security-Policy header