ETag vs Last-Modified: Which Revalidation Strategy Should You Use?

Overview

Here is the short version: if you need precise validation of changing content, ETag is usually the stronger tool. If you want broad compatibility, simpler behavior, and lower implementation complexity, Last-Modified is often enough. In many real deployments, the best answer is not “pick one forever,” but “use the right validator for the resource type.”

Both headers support conditional requests. Instead of downloading the full response again, the client or edge can ask, in effect, “Has this changed since the copy I already have?” If the answer is no, the origin can return 304 Not Modified with no body. That saves bandwidth, reduces origin load, and can improve perceived performance even when content is not fully cacheable for long periods.

The two mechanisms work differently:

• ETag is a validator token attached to a specific representation of a resource. The client later sends it back with If-None-Match.
• Last-Modified is a timestamp representing when the resource last changed. The client later sends it back with If-Modified-Since.

At a protocol level, both are valid. At an operational level, they behave differently enough that your choice affects origin CPU cost, cache hit behavior, edge caching consistency, and debugging effort.

A useful framing for modern website caching is this:

• Use versioned static assets whenever possible so revalidation matters less.
• Use Last-Modified for content where a trustworthy modification time exists and second-level precision is acceptable.
• Use ETag where exact representation matching matters, especially for generated responses or APIs.
• Be careful with ETag across multiple origins or CDN layers if different servers can emit different tags for the same practical content.

If you need a broader refresher on response freshness before revalidation starts, see HTTP Cache-Control Header Reference for Developers. Revalidation works best when it is paired with sensible Cache-Control policy rather than treated as a stand-alone feature.

How to compare options

The right comparison is not about which header is “better” in the abstract. It is about what kind of object you are serving, how many layers sit between user and origin, and how expensive it is to determine whether content changed.

Use these five questions to choose a strategy.

1. How exact does change detection need to be?

ETag can validate the exact response representation. That matters when small differences are meaningful: generated JSON, personalized but cache-keyed API responses, or HTML assembled from multiple components.

Last-Modified is coarser. If two updates happen within the same timestamp granularity, or if your app cannot reliably track true modification time, it may miss meaningful changes or force unnecessary revalidation.

Decision rule: if exact byte-level or representation-level validation matters, favor ETag.

2. Can your origin generate validators consistently?

This is where many caching implementations become fragile. An ETag is only useful if it is stable for the same content. In clustered environments, weakly coordinated app servers, build pipelines, compression differences, or middleware that rewrites output can produce different ETags for effectively equivalent responses. That can lower cache efficiency and create confusing CDN behavior.

Last-Modified is often easier to keep consistent because it can map to a database update timestamp, file mtime, or publish date. It is simpler to reason about across multiple servers.

Decision rule: if you cannot guarantee ETag consistency across origins, Last-Modified may be safer.

3. What sits in front of the origin?

CDNs, reverse proxy cache layers, and edge caching platforms all influence revalidation. Some platforms forward conditional headers to origin, some collapse requests, some transform content, and some make it easier to cache based on surrogate logic than on browser-facing validators alone.

In edge-heavy stacks, consistency matters more than cleverness. If your CDN compresses responses differently by client capability, or rewrites HTML, an origin-generated strong ETag may no longer represent the final payload delivered at the edge. That does not always break caching, but it can complicate conditional request logic.

Decision rule: in multi-layer edge delivery networks, prefer the validator your stack can preserve reliably end to end.

4. Is origin CPU or bandwidth the bigger constraint?

Revalidation reduces bandwidth, but it does not remove every origin cost. The origin still needs to evaluate the condition. If generating an ETag requires hashing a large dynamic response on every request, that precision may cost more than it saves. If Last-Modified can be checked from a lightweight timestamp field, it may be operationally cheaper.

Decision rule: when origin generation cost is high, pick the lightest reliable validator.

5. How easy is it to debug in production?

Last-Modified is easy to inspect. You can usually tell at a glance whether the timestamp is sensible. ETags can be opaque strings generated by your app, web server, or framework. That opacity is fine when the system is well understood; it is less fine when you are troubleshooting stale HTML, low cache hit ratio, or unexpected 200s from origin.

Decision rule: if your team needs simplicity and predictable troubleshooting, Last-Modified is often easier to operationalize.

Feature-by-feature breakdown

This section compares ETag vs Last-Modified in the places where website speed optimization teams usually feel the difference.

Precision

ETag wins on precision. It can identify a specific representation, which makes it well suited to APIs, dynamic pages, and responses assembled from multiple data sources. If the content changes, the tag changes.

Last-Modified is approximate. It depends on a meaningful timestamp and on the time resolution available. For many websites, that is enough. For fast-changing resources, it may not be.

Implementation complexity

Last-Modified usually wins on simplicity. If a file has an mtime or a record has an updated-at field, you already have most of what you need. This makes it a practical default in CMS-driven sites, blogs, documentation sites, and many WordPress caching setups.

ETag can be simple or messy depending on how it is generated. File-based static assets are straightforward. Dynamic HTML rendered through multiple app nodes is not always straightforward.

Multi-server consistency

Last-Modified is often more stable across clusters. A shared content database can emit a common timestamp. ETag requires discipline if content can be rendered differently by node, middleware, or compression path.

This matters for managed caching solutions and origin pull CDN setups where several origins may answer the same URL.

CDN and edge behavior

For Cloudflare caching, reverse proxies, Nginx caching setup, or Varnish-style architectures, validators are useful, but freshness directives and cache keys still do most of the heavy lifting. Revalidation helps most when content is cacheable for short periods or when browsers frequently revisit objects that have not changed.

ETag caveat: if the edge platform transforms responses, compresses content differently, or normalizes headers in transit, test whether ETag remains meaningful in your delivery path.

Last-Modified caveat: if your app republishes content without updating the timestamp correctly, the edge can keep validating against stale metadata.

Static assets

For hashed CSS, JS, fonts, and images, neither ETag nor Last-Modified should be your primary strategy. The stronger pattern is long-lived caching with file versioning in the URL. If the asset URL changes on deploy, browsers and CDNs can treat it as a new object, and revalidation becomes far less important.

If you still need a validator, Last-Modified is usually adequate for static files, while ETag can add precision. But the real win is proper immutable asset versioning and a clear policy for how to cache static assets.

HTML documents

For HTML, the answer depends on how dynamic the page is. A mostly editorial page with occasional updates often works well with Last-Modified. A page assembled from multiple data sources, feature flags, or fragments may benefit from ETag if the tag is generated from the final representation or a reliable revision identifier.

For WordPress caching, many teams get better results by caching anonymous HTML aggressively at the edge and using purge rules on content updates. Revalidation still matters for browsers and shorter-lived responses, but it should complement purge strategy, not replace it.

APIs

ETag is often the better fit for APIs. API caching strategy tends to care about exact resource state. Clients may poll often, payloads may be expensive, and conditional requests can significantly cut bandwidth. If a record version, row checksum, or canonical revision ID exists, ETag is a strong choice.

Last-Modified also works for APIs, especially read-heavy resources with clear update times. But if API consumers care about exact changes, ETag is the safer pick.

Partial content and weak vs strong validation

One subtle point: not all ETags are equal. Strong ETags imply exact representation matching. Weak ETags are looser and may treat semantically equivalent responses as “the same” for cache validation purposes. Weak tags can be useful, but they add nuance. If your team is already struggling with opaque caching behavior in production, adding weak/strong semantics without a clear need may complicate troubleshooting.

Last-Modified does not have this specific distinction, which is another reason it feels easier operationally.

Origin load and cache hit ratio

Revalidation is not the same as a full cache hit. A browser or edge still has to ask a question. That means if your current problem is poor cache hit ratio at the CDN, changing validators alone may not solve it. You may need to revisit TTLs, cache keys, cookie bypass rules, and purge patterns.

For that broader operational view, articles like Monitoring Cache Performance for Live Analytics: Metrics That Matter in Ops Environments and Predictive Cache Monitoring: Using Forecasting to Spot Hit-Rate Declines Before Users Feel Them are useful follow-ons.

Best fit by scenario

If you need a direct recommendation, use this section as the decision guide.

Scenario: versioned static assets on a modern site

Best fit: neither as the primary strategy; use long TTLs and versioned URLs.

Why: edge caching and browser caching work best when the asset URL changes on deploy. Validators become secondary. If you need one, Last-Modified is fine; ETag is acceptable if generated consistently.

Scenario: editorial pages, docs, blog posts, and CMS content

Best fit: Last-Modified by default.

Why: content changes are tied to publish or update times, and the header is easy to inspect and reason about. This is often a good fit for website caching on content-heavy sites and for many WordPress caching setups.

Scenario: dynamic HTML with assembled components

Best fit: ETag if you can generate it from a stable revision signal; otherwise Last-Modified based on a reliable page revision timestamp.

Why: precision matters more, but only if your validator remains consistent across servers and transformations.

Scenario: APIs with frequent polling

Best fit: ETag first, Last-Modified second.

Why: APIs often benefit from exact validation using If-None-Match. This can reduce payload transfer while keeping clients current.

Scenario: multi-origin CDN or reverse proxy cache in front of heterogeneous backends

Best fit: whichever validator you can keep consistent across every origin node, often Last-Modified.

Why: a theoretically better validator that varies by node hurts operational predictability. In edge caching, consistency is usually more valuable than elegance.

Scenario: WooCommerce or highly personalized application pages

Best fit: revalidation only for cacheable shared responses; avoid trying to solve personalization with validators.

Why: dynamic commerce pages usually require careful cache bypass and segmenting. Validators help on shared resources, product data feeds, and semi-static pages, but they are not a substitute for correct WooCommerce cache rules or session-aware cache keys.

Scenario: SMB site choosing a managed caching solution

Best fit: favor the simpler validator unless your platform clearly supports stable ETag behavior.

Why: most small teams benefit from clear defaults and easier debugging. If you are evaluating providers, pair this topic with broader CDN comparison work such as Cloudflare vs Bunny.net vs Fastly: CDN Features and Pricing Compared and Best CDN Services for Small Business Websites.

As a practical default, many teams can use the following rule set:

1. For versioned static assets: cache long, do not rely on revalidation as the main control.
2. For CMS pages and content records: start with Last-Modified.
3. For APIs and exact-state resources: start with ETag.
4. For clustered environments with inconsistent app output: distrust ETag until proven stable.
5. For CDN-heavy stacks: test validators through the full edge-to-origin path, not just at localhost.

When to revisit

Your revalidation strategy should be reviewed whenever the delivery path changes, not only when content changes. This is especially true for edge caching, because a small platform adjustment can change how validators behave in the real world.

Revisit your choice when any of the following happens:

• You add or replace a CDN, reverse proxy cache, or managed caching layer.
• You move from a single origin to multiple app nodes.
• You enable response compression, HTML rewriting, image optimization, or edge transformations.
• You shift from static publishing to dynamic rendering.
• Your API clients start polling more frequently.
• You see rising origin traffic despite stable user traffic.
• You notice low cache hit ratio, stale responses, or confusing 200/304 behavior in logs.

Use this quick audit checklist:

1. Inspect current headers for representative pages, assets, and API endpoints.
2. Confirm freshness policy first: max-age, s-maxage, stale controls, and cache bypass rules.
3. Verify validator consistency across all origin nodes.
4. Test conditional requests manually with curl using both If-None-Match and If-Modified-Since where relevant.
5. Check edge behavior from multiple regions if a CDN is involved.
6. Measure origin request reduction, not just browser behavior.
7. Document exceptions for HTML, API, and commerce routes so future changes do not undo your gains.

A sensible action plan for most teams is to pick one representative resource from each category—static asset, HTML page, API response—and validate your assumptions end to end. If the results are clean, expand the pattern. If not, simplify. Revalidation works best when it is boring, predictable, and documented.

The practical takeaway is this: ETag vs Last-Modified is not a winner-take-all decision. Choose ETag when exactness is valuable and stable generation is realistic. Choose Last-Modified when simplicity, compatibility, and operational clarity matter more. And for static assets, invest your energy in cache versioning and edge policy before tuning validators.