Last-Modified Inspect

What does this tool do?

Parse Last-Modified / If-Modified-Since and show readable dates. If both are present, it also shows a match check (possibility of 304).

Useful for debugging cache issues such as missing or excessive 304 responses.

Last-Modified basics

• Last-Modified is the time when the resource was last changed.
• If-Modified-Since indicates the client’s cached timestamp and is used for revalidation.
• If the server decides it’s unchanged, it returns 304.

Syntax (date formats)

HTTP-date has multiple formats, but in practice IMF-fixdate is used (e.g., Sun, 06 Nov 1994 08:49:37 GMT).

• Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
• If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

Glossary (terms used on this page)

• Revalidation: checking freshness before reuse when stale or when required (e.g., no-cache).
• Conditional request: a request with If-Modified-Since or If-None-Match.
• Fresh / stale: whether the cached response is within lifetime or expired.

304 (Not Modified) and date comparison

If the If-Modified-Since value is equal to or later than Last-Modified, the server may return 304.

• No 304: Last-Modified changes/missing, or If-Modified-Since is not sent
• Too many 304: Last-Modified not updated, clock skew, or fixed timestamps

Examples (copy-paste to understand)

Start by checking Last-Modified in response headers, then confirm If-Modified-Since is actually sent in request headers.

• Response: Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
• Request: If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT (>= may result in 304)
• No conditional header: not revalidating → likely 200

Cache-Control and revalidation

Last-Modified is used during revalidation. Depending on Cache-Control, revalidation can be frequent or never happen.

• Short max-age: If-Modified-Since sent more often
• no-cache: revalidate every time (304 may omit body)
• immutable: reduces revalidation (pairs well with hash filenames)

Common reasons you don’t get 304

• Last-Modified is missing (common for dynamic responses)
• If-Modified-Since isn’t sent (cache policy, DevTools Disable cache, Service Worker, etc.)
• Clock skew (server/build/container time)
• Sub-second update frequency (Last-Modified cannot represent it)

Precision notes (1-second granularity)

Last-Modified is second-level. For high-frequency changes, use ETag or another versioning strategy.

Server-side notes (don’t use generation time)

Last-Modified should represent the last change time. If you set it to the current time on every response, conditional requests won’t match and you’ll lose 304.

• Static files: using file mtime is typical
• DB/API: use an updated_at timestamp
• Build artifacts: build/commit time works (but may invalidate many assets at once)

Notes behind CDN/proxies

CDNs/proxies may not pass through origin Last-Modified as-is; transforms or cache rewrites can change it.

How to test (revalidate with curl)

Fetch Last-Modified, then send it back as If-Modified-Since to confirm behavior (replace the URL).

• Fetch: curl -I https://example.com/asset.js
• Revalidate: curl -I -H \"If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT\" https://example.com/asset.js
• Compare: check status (200/304) and also verify Last-Modified/Cache-Control

Typical use cases

• Revalidation checks when ETag is unavailable
• No 304; always 200
• Over-caching; updates not reflected

Debugging workflow (recommended)

• Use Response Headers Parser to check Last-Modified / Cache-Control
• Check If-Modified-Since via Request Headers Parser
• Use this tool to compare readable dates

Related tools

• ETag Inspect
• Cache-Control Inspect
• Response Headers Parser / Request Headers Parser
• Vary Inspect

Recommendations (practical)

• Ensure it reflects actual modifications, not build time
• Always include validators for APIs/HTML
• Pair with Cache-Control to enable revalidation

What this tool does

• Parse Last-Modified / If-Modified-Since dates
• Compare dates (equal/newer/older)
• Support header lines and multi-line paste

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: Last-Modified / If-Modified-Since

FAQ

References

1. RFC 9110
2. RFC 9111
3. MDN: Last-Modified
4. MDN: If-Modified-Since
5. MDN: HTTP caching

Next to view (diagnostic order)

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

1. How to Diagnose Missing 304 Responses — Trace ETag/Last-Modified and If-* round trips to isolate missing 304 behavior
2. Expires Inspect — Parse Expires and Date to inspect freshness behavior
3. Vary Inspect — Parse Vary and visualize cache variation keys
4. Age Inspect — Parse Age to estimate shared-cache residency time
5. ETag Inspect — Parse ETag and If-None-Match consistency
6. Cache Validator Overview — Summarize relationships among ETag/Last-Modified validators
7. ETag Builder — Build ETag values for testing and operations
8. If-None-Match Inspect — Parse If-None-Match and inspect revalidation conditions

Same-theme links

Cache Validators

Connect ETag/Last-Modified and If-* to judge revalidation flow

• Cache Validator Overview — Summarize relationships among ETag/Last-Modified validators
• ETag Inspect — Parse ETag and If-None-Match consistency
• ETag Builder — Build ETag values for testing and operations
• If-None-Match Inspect — Parse If-None-Match and inspect revalidation conditions
• If-Match Inspect — Parse If-Match and inspect update preconditions
• If-Modified-Since Inspect — Parse If-Modified-Since and inspect conditional retrieval
• If-Unmodified-Since Inspect — Parse If-Unmodified-Since and inspect precondition behavior