The ETag (Entity Tag) HTTP response header is an opaque identifier assigned by a web server to a specific version of a resource.

Strong vs. weak validators

RFC 9110 Section 8.8.3 defines two types of entity tags:

1. Strong ETag

Indicates byte-for-byte identical representation:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Strong ETags can be used for range requests (Range: bytes=...) and concurrency control.

2. Weak ETag

Prefixed with W/, indicating that representations are semantically equivalent even if minor byte differences exist (e.g., compression changes or whitespace):

ETag: W/"0815"

Conditional revalidation flow

When a client caches an ETag, subsequent requests include If-None-Match:

GET /v1/users/892 HTTP/1.1
Host: api.example.test
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
  • If unchanged: Server returns HTTP 304 Not Modified with no payload body.
  • If modified: Server returns HTTP 200 OK with the new representation and a new ETag.

For more details on revalidation, see our guide on If-None-Match Header.

How to test with curl

Fetch the ETag of a resource with curl:

curl -i https://api.example.test/v1/users/892

Key takeaway

The ETag header provides a unique fingerprint for a resource representation. When combined with If-None-Match, it eliminates redundant data transfers by returning 304 Not Modified when cached content remains valid.