Validators: ETag and Last-Modified

A validator is a value the server sends with a response so a client can later ask whether the resource has changed. An ETag, or entity tag, is an opaque version label, such as "v7", that changes whenever the resource does; Last-Modified is the time of the last change. A client sends the validator back with its next request, and the server compares.

An ETag works like the edition number printed on a timetable: compare numbers, and you know whether yours is current without reading every line. The comparison breaks for weak ETags, which say "the same in substance", an idea a timetable has no use for.

HTTP/1.1 200 OK
ETag: "v7"
Last-Modified: Wed, 07 Oct 2026 09:12:00 GMT
Content-Type: application/json

Strong and weak forms of an ETag:
ETag: "a3f9c2"
ETag: W/"a3f9c2"

ETag. The server chooses the value, often a hash of the body or a version number from the database. The client must treat it as opaque and send it back exactly, quotes included.

Last-Modified. A date with one-second precision. It is easy to produce from an updated_at column, but two changes within one second share a timestamp, and a server with several copies of the data may disagree on it. Where both are sent, the ETag is preferred.

Strong and weak. A strong ETag promises the bytes are identical. A weak ETag, written with a W/ prefix, promises only that the two are equivalent for the client's purposes, for example the same data with a different whitespace layout or compression. Servers and CDNs sometimes weaken a strong tag when they transform the body.

Which comparison applies. If-None-Match, used to check whether a cached copy is still current, uses weak comparison: W/"a3f9c2" matches "a3f9c2". If-Match, used to make a write conditional, uses strong comparison: a weak tag never matches, because a write must be based on exactly the bytes the client read.

So send an ETag on every resource a client may cache or edit, and make it strong if clients will send it in If-Match.