Launch cache planning
Choose browser and CDN caching behavior before a page, asset, or API ships.
Documentation
HTTP Cache Planner documentation
Build Cache-Control recipes or explain pasted header values with TTL math, companion header guidance, and practical caching notes.
Overview
Use it when the format needs to change, not the meaning
Use HTTP Cache Planner when you need to choose a cache policy before implementation or make sense of a pasted Cache-Control value after the fact.
Header explanation
Translate pasted Cache-Control values into readable TTL and directive guidance.
Analyzer follow-up
Move from “what headers exist” to “what should these headers be.”
Supported inputs
Bring clean source text and keep the direction straight
- Build mode starts from opinionated recipes for versioned assets, HTML, APIs, CDN-backed pages, and private content.
- Explain mode accepts either a raw Cache-Control value or a full Cache-Control header line.
- Optional ETag, Last-Modified, Expires, and Vary values refine the companion-header guidance.
Walk through it
Follow the same sequence you see in the tool
Workflow
Build a policy
Use this flow when you are deciding what the response should send.
- Pick the recipe that matches the response type.
- Adjust browser, shared-cache, and stale windows to fit the freshness goal.
- Copy the normalized Cache-Control value and review the implementation notes before you wire up the response headers.
Workflow
Explain a pasted header
Use this flow when a live response already has Cache-Control and you want to interpret it.
- Paste the Cache-Control value or full header line.
- Add any companion headers you already know, such as ETag or Vary.
- Review the parsed directives, TTL windows, and cautions before changing the policy.
What you get
Check the result before you copy it into the next step
Normalized Cache-Control value
A copy-ready policy string is available after generation or parsing.
How this policy behaves
Browser, shared-cache, and stale windows are translated into plain-language timing so you can tell what stays fresh where.
Implementation notes
This is a short glossary-style explanation of the related headers around the policy. It tells you what ETag, Last-Modified, Expires, and Vary mean here, and whether each one is recommended, present, or usually unnecessary.
Avoid these mistakes
Small input problems create the biggest conversion errors
Using immutable on unstable URLs
Reserve immutable for versioned URLs that change whenever the content changes.
Mixing private and shared-cache intent
Avoid combining private responses with shared-cache goals unless the policy truly fits the traffic.
Skipping live verification
Use HTTP Header Analyzer after implementation when you need to confirm the live response matches the plan.
Glossary
Decode the terms before you act on them
This section translates the most technical labels on the page into plain language so you can interpret the output without opening another tab.
Cache-Control
Cache-Control is the response header that tells browsers and shared caches how long a response may be reused and under what conditions.
TTL
TTL stands for time to live. In caching it is the amount of time a response may stay fresh before it should be revalidated or replaced.
s-maxage
s-maxage is the shared-cache TTL. It applies to CDNs and proxy caches instead of the end user’s browser cache.
ETag
ETag is a response validator that lets a client ask whether its cached copy still matches the current version on the server.
Vary
Vary tells caches which request headers can change the response, such as language or compression preferences.
immutable
immutable tells the browser the response should not be revalidated during its freshness window because the URL is expected to change when the content changes.