b2KIT

ETag Header Checker

Check and validate ETag response headers for proper caching behavior with weak vs strong ETag analysis.

Tested tool guide Tested browser tools Checked August 16, 2026

What ETag Header Checker does and how it behaves

An ETag response header identifies a selected representation with one quoted entity-tag. This checker examines the entered header value, determines whether it matches HTTP entity-tag syntax, and distinguishes a strong tag such as "abc" from a weak tag such as W/"abc". The distinction is semantic, not a judgment about hash length or cryptographic quality. A frequent mistake is treating W/ as an invalid prefix. It is valid syntax, but it signals that the validator is unsuitable wherever HTTP requires strong comparison.

How the result is produced

1

Entity-tag syntax

HTTP defines an entity-tag as an optional, case-sensitive W/ weakness indicator followed by an opaque tag in double quotes. The checker evaluates that complete shape. An unquoted token, lowercase w/, missing slash, or text outside the quoted tag does not form the response header's entity-tag syntax, even if the value resembles a file hash or version identifier.

2

Comparison strength

A tag without W/ is strong; one with W/ is weak. Strong comparison requires both tags to be strong and their opaque tag text to match. Weak comparison ignores weakness and compares the opaque tag text. This matters because conditional request fields select comparison rules: If-Match uses strong comparison, while If-None-Match uses weak comparison.

Good uses

  • Audit an origin or application response after changing ETag generation, especially when a validator appears unquoted or has a malformed weakness prefix.
  • Investigate why an If-Match precondition does not succeed when the resource response supplies a weak ETag.
  • Compare validators captured from two responses and identify whether their quoted opaque values match while their weak or strong classifications differ.

Limits and checks

  • Syntactic validity does not prove that the server changes the ETag whenever the representation changes. That behavior must be tested across actual responses.
  • An ETag alone does not establish cache freshness or general cacheability. Cache-Control, request method, response status, and other HTTP rules remain relevant.
  • Do not paste If-Match or If-None-Match syntax and interpret it as an ETag response value. Wildcards and comma-separated lists belong to those request fields, not to the ETag field.

Common questions

Does a weak ETag disable browser caching?

No. A weak ETag can still support cache revalidation: a client can send it in If-None-Match, whose comparison is weak. Weakness means the validator can identify representations the origin considers semantically equivalent; it does not set freshness or cacheability. Cache-Control and other response metadata govern those separate questions.

Do W/"v1" and "v1" count as the same ETag?

They contain the same opaque tag, but they do not match under every comparison rule. Weak comparison treats W/"v1" and "v1" as matching. Strong comparison does not, because both operands must be strong. The checker's weak or strong classification therefore matters even when the text inside the quotation marks is identical.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools