ETag & Last‑Modified Validator - Online Check Cache Headers

An ETag (Entity Tag) is an HTTP response header that identifies a specific version of a resource. It acts like a fingerprint — when the resource changes, the ETag changes. Browsers use ETags in conditional requests (with If-None-Match) to ask servers: "Has this resource changed since I last fetched it?" If not, the server returns 304 Not Modified, saving bandwidth. ETags can be strong (exact byte match) or weak (prefixed with W/, indicating semantic equivalence).

Last-Modified is a timestamp indicating when the resource was last changed on the server. Browsers use If-Modified-Since for conditional requests. Unlike ETags (which detect any content change), Last-Modified is time-based and has 1-second resolution — if a resource changes twice within the same second, Last-Modified may not catch it. ETags are more precise. Best practice: use both for maximum cache efficiency and compatibility.

Cache headers directly impact page load speed, which is a confirmed Google ranking factor. Properly configured ETags, Last-Modified, and Cache-Control headers reduce server load and enable faster repeat visits. Googlebot also respects cache headers during crawling — efficient caching means Google can crawl more pages per session. Additionally, CDNs rely on these headers for edge caching, further improving global load times and Core Web Vitals scores.

A strong ETag (e.g., "abc123") guarantees byte-for-byte identical content. A weak ETag (e.g., W/"abc123") indicates the content is semantically equivalent but may differ in non-essential ways (like different compression or minor formatting). Weak ETags are useful for dynamic content where exact byte matching is impractical. For static assets (JS, CSS, images), strong ETags are preferred for precise cache validation.

A 304 Not Modified response means the client's cached version is still fresh — the server tells the browser "your copy is still good, use it." This response has no body, saving significant bandwidth (especially for large resources). It's triggered when a conditional request header (If-None-Match or If-Modified-Since) matches the current server state. Proper 304 handling is essential for efficient web caching strategies.

• max-age=N — Cache for N seconds from request time
• s-maxage=N — Like max-age but for shared/CDN caches only
• public — Can be cached by any cache (browser, CDN, proxy)
• private — Only for the end user's browser, not shared caches
• no-cache — Must revalidate with server before each use
• no-store — Do not cache at all (use for sensitive data)
• must-revalidate — Must check with server after expiration
• immutable — Content will never change (great for versioned assets)

Use this tool to inspect ETag and Last-Modified headers, then verify conditional requests. You can also use browser DevTools (Network tab) to observe 304 responses on repeat visits. For automated testing, tools like curl -I -H "If-None-Match: <etag>" let you manually send conditional requests. A well-configured server should return 304 when the ETag matches and 200 with new content when it doesn't.

Common reasons: dynamic content generated by scripts may not set these headers; misconfigured servers (NGINX/Apache) may have conditional header generation disabled; CDN or reverse proxy may strip them; application code may explicitly remove them for "security" reasons (misguided). Check your server config and ensure your framework/application is configured to emit these headers for cacheable resources.

For versioned static assets (JS, CSS, fonts, images with hashed filenames): use Cache-Control: public, max-age=31536000, immutable (1 year). These files never change, so the browser can skip revalidation entirely. For unversioned assets: use Cache-Control: public, max-age=86400 with both ETag and Last-Modified for revalidation. Always combine with a CDN for optimal global delivery.

Due to CORS (Cross-Origin Resource Sharing) policies, browsers restrict reading response headers from cross-origin requests. This tool attempts direct requests — they'll succeed for same-origin URLs or servers with permissive CORS headers. For other URLs, enable the CORS Proxy option, which routes requests through a proxy that bypasses browser restrictions. Alternatively, use command-line tools like curl -I for unrestricted header inspection.