Expires Inspect

Analyze cache-related headers across layers. No input is sent to a server. Use it for first-pass revalidation and CDN mismatch troubleshooting.

Status

Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.

How to use

Paste Expires (and optionally Date) and click “Parse”. It shows parsed dates and whether it’s expired (header lines/multi-line paste OK; full response headers OK).

Notes (this tool)

  • Real caching behavior is often dominated by Cache-Control; use Cache-Control Inspect together.

About this page

What does this tool do?

Parse Expires / Date and display the expiration time (when it becomes stale). If both are present, it checks whether Expires is after/before Date.

Useful for diagnosing “caching not working”, “over-caching”, or “how long will it stay stale?”.

Expires basics

  • Expires is the response expiration time (as an absolute date).
  • Date is the time the response was generated.
  • If Expires is before Date, the response is already stale.

Relationship to Cache-Control (most important)

In practice Cache-Control often dominates caching behavior, so Expires alone can be misleading. Check Cache-Control (max-age/no-store/no-cache, etc.) first, then interpret Expires.

  • With max-age: freshness is controlled by seconds; Expires becomes secondary
  • no-cache: revalidation is required regardless of Expires
  • no-store: not stored, so Expires is mostly irrelevant

Syntax (date formats)

Expires uses HTTP-date. In practice IMF-fixdate is used (e.g., Wed, 21 Oct 2015 07:28:00 GMT).

  • Expires: Wed, 21 Oct 2015 07:28:00 GMT
  • Date: Wed, 21 Oct 2015 07:00:00 GMT

Glossary (terms used on this page)

  • Fresh / stale: whether a cached response is within its lifetime or expired.
  • Shared cache: a cache shared by many users (CDN/proxy).
  • Revalidation: checking before reuse of a stale cache entry.

Examples (common patterns)

  • Past Expires: Expires: 0 or a past date → often intended “do not cache”
  • Future Expires: can stay fresh until that time (subject to Cache-Control)
  • Missing Date: usually present, but can be absent depending on environment

Why check Date too? (detect clock skew)

Expires is an absolute timestamp. If the server/CDN clock is off, it may look unexpectedly in the past/future. Comparing with Date helps reveal skew.

  • Expires < Date: likely already stale
  • Expires far in the future: possible rewrite/bug/unintended config

Common pitfalls

  • Misreading contradictions between Cache-Control and Expires (max-age often wins)
  • Clock skew makes Expires look unexpectedly past/future
  • CDN may rewrite/add headers (origin differs from edge)

Common issues behind CDN/proxies

CDNs don’t always pass through origin Expires/Cache-Control. They can override or add headers via caching rules.

  • Origin vs edge Expires differs: check CDN cache policy
  • Depending on Vary/cache key design, stale variants can mix

How to test (check Expires/Date with curl)

Start by fetching only headers and inspect Expires/Date/Cache-Control (replace the URL).

  • Fetch: curl -I https://example.com/asset.js
  • If CDN vs origin differs, compare headers from both paths

Interpret Expires together with Cache-Control (max-age/no-cache/no-store).

Troubleshooting checklist by symptom

  • Caching not working: check past Expires, Vary: *, no-cache/no-store, and CDN bypass rules
  • Over-caching: check far-future Expires, large max-age, immutable, and whether filenames are versioned
  • Expires looks wrong: compare with Date and suspect clock skew (server/CDN)

Debugging workflow (recommended)

  • Paste response headers into Response Headers Parser and check Cache-Control/Expires/Date
  • Use this tool to parse Expires/Date and classify past vs future
  • Also verify ETag/Last-Modified for revalidation when stale
  • Cache-Control Inspect
  • ETag Inspect
  • Last-Modified Inspect
  • Response Headers Parser
  • Vary Inspect

Recommendations by use case

  • Prefer Cache-Control; treat Expires as a fallback
  • For HTML, use short Expires with validators
  • For static assets, long Expires + versioned URL

What this tool does

  • Parse Expires / Date (UTC/GMT)
  • Check whether Expires is after/before Date
  • Extract Expires/Date from full response headers

Operational notes

  • Cache behavior changes across browser, CDN, and proxy layers, so compare captures from the same observation point.
  • Header-only diagnosis may be insufficient. Also review application cache invalidation strategy and key design.

Referenced specs

  • RFC 9110 (HTTP Semantics)
  • RFC 9111 (HTTP Caching)
  • MDN: Expires / Date

FAQ

Which wins: Expires or max-age?

In practice, max-age (Cache-Control) often takes precedence. Expires is commonly used for compatibility or as a secondary signal.

How is Expires: 0 treated?

Interpretation can vary; a safer design is to rely on explicit Cache-Control instead.

Is missing/weird Date a problem?

Missing/invalid Date makes Expires comparisons and skew detection harder. Check where headers are set (app/proxy/CDN) and fix at the responsible layer.

References

  1. RFC 9110
  2. RFC 9111
  3. MDN: Expires
  4. MDN: Date
  5. MDN: HTTP caching

These links are generated from site_map rules in recommended diagnostic order.

  1. Age Inspect — Parse Age to estimate shared-cache residency time
  2. Last-Modified Inspect — Parse Last-Modified and If-Modified-Since
  3. If-Modified-Since Inspect — Parse If-Modified-Since and inspect conditional retrieval
  4. Vary Inspect — Parse Vary and visualize cache variation keys
  5. Cache Not Working Troubleshooting — Troubleshoot cache-not-working symptoms step by step from headers
  6. HTTP Cache Mismatch — Identify root causes of cache mismatches
  7. Cache Response Analyzer — Judge cacheability from response headers
  8. Cache Key Inspect — Visualize cache-key splits from URL, Vary, and headers

Cache Control

Diagnose delivery policy across Cache-Control/Expires/Age