ETag

An ETag is an HTTP validator that identifies a specific version of a resource. Clients send it back to skip unchanged responses and avoid overwriting concurrent edits.

networking

Definition

An entity tag (ETag) is an HTTP response header containing an opaque validator for a selected representation of a resource. A client echoes it in If-None-Match for cache revalidation or If-Match for conditional writes, letting the server compare versions without transferring the full body.

Context and scope

ETags power efficient caching through 304 Not Modified responses and safe concurrent updates through optimistic concurrency. Strong ETags compare byte-for-byte, while weak ETags prefixed with W/ assert only semantic equivalence.

Common misconceptions

An ETag must be a checksum computed over the response body
ETags behave identically across a CDN and origin with no configuration
Sending If-Match prevents every possible race condition

Anti-patterns

Deriving ETags from mutable metadata such as last-modified time alone
Serving the same ETag from multiple servers for different content
Ignoring If-None-Match and always returning 200 with a full body

Related concepts

Related examples

Authoritative source

https://www.rfc-editor.org/rfc/rfc9110.html

How it works

The server assigns an opaque tag to each representation of a resource, typically a hash of the content or a version identifier.

HTTP/1.1 200 OK
ETag: "v17-8f2c"
Cache-Control: public, max-age=60

A client repeats the tag in If-None-Match; if the representation is unchanged the server answers 304 Not Modified without a body. For writes, If-Match makes the update conditional: the server applies it only when the current tag matches, otherwise it returns 412 Precondition Failed. Strong tags assert byte equality, while weak tags such as W/"abc" assert only semantic equivalence and cannot be used for range requests.

When to use it

Use ETags for cache revalidation of API responses, for immutable asset versioning, and for optimistic concurrency on updates. Compared with Last-Modified, which has one-second granularity and can miss rapid changes, ETags are usually more precise. For large downloads, If-Range combines a validator with range requests.

Trade-offs

Hashing large responses costs CPU, while version counters are cheap but must change on every write. CDNs and compression can transform bytes, so strong tags may be weakened or rewritten at the edge; ensure origin and edge agree. Tags drift in a load-balanced fleet unless they derive from shared content or a shared version.

Concrete example

curl -sI https://api.example.com/items/42 | grep -i etag
# ETag: "v17-8f2c"
curl -s -o /dev/null -w "%{http_code}\n" \
  -H 'If-None-Match: "v17-8f2c"' https://api.example.com/items/42
# 304
curl -s -X PUT https://api.example.com/items/42 \
  -H 'If-Match: "v17-8f2c"' -H 'Content-Type: application/json' \
  -d '{"price":1200}'
# 412 if another writer changed the item first

An ETag need not be a checksum, and receiving one does not guarantee it is safe across servers. If-Match prevents lost updates only when every writer uses it. Related concepts include HTTP Caching, Cache Invalidation, Content Delivery Network, and Optimistic Concurrency.