ETag Weak / Strong Validator | RFC 7232 Strong vs Weak Comparison
Drop two HTTP ETag header values side by side and see how RFC 7232 §2.3 compares them. The tool detects the W/ prefix, extracts the quoted opaque value, and reports both a strong match and a weak match — so you know whether a cache hit, a conditional request, or a Range request would actually succeed.
💡 About this tool
If you've ever stared at a response and wondered why 304 Not Modified never fires, ETag comparison rules are usually the culprit. HTTP defines two flavors: a strong validator ("abc") and a weak validator (W/"abc"). RFC 7232 says strong comparison is true only when both tags are strong and the opaque values are byte-identical, while weak comparison ignores the W/ prefix and only checks the values.
That distinction is not academic. Range requests and If-Range only accept strong validators, so if your server hands out W/"..." and a client tries a partial download, the server falls back to a full 200 response instead of a 206. Meanwhile If-None-Match revalidation is happy with weak tags. Paste both headers here and the recommendation line tells you exactly which conditional headers the pair would satisfy.
It runs entirely in your browser, so you can spot-check ETags straight out of curl -I or your DevTools Network tab without piping anything to a server.
🧐 Frequently Asked Questions
Does W/"abc" equal "abc"?
Weak match: yes. Strong match: no. The moment either tag carries W/, strong comparison rules it out, even though the values are identical.
Why does a bare value like abc123 show "invalid syntax"?
RFC 7232 requires the opaque value to be wrapped in double quotes. abc123 without quotes is not a syntactically valid entity-tag, so it can't be compared.
Are ETag values case-insensitive?
No. The opaque-tag is compared character by character, so "ABC" and "abc" are different, and internal whitespace counts too.
Which one do I need for resumable downloads?
A strong validator. Range / If-Range reject weak tags to avoid stitching together bytes from two semantically-equal-but-not-identical representations. Aim for a pair where Strong match reads YES.
Can it handle hash-style or structured ETags?
Yes. Whatever sits inside the quotes is treated as opaque, so hex digests like "686897696a7c876b7e" and versioned tags like "v2-2024-01" compare exactly as written.
📚 Fun Facts
The ETag header dates back to HTTP/1.1 in RFC 2616, but the strong/weak comparison algorithm wasn't cleanly specified until RFC 7232 in 2014. Weak validators exist for a very practical reason: some responses are semantically identical yet differ byte-for-byte — think of a page re-gzipped at a different compression level, or content with an embedded timestamp. Tagging those with a strong ETag would break 304 caching, so W/ was introduced as an escape hatch meaning "equivalent enough." A classic gotcha: Apache historically derived ETags from a file's inode, size, and mtime, which meant the same file served from two load-balanced boxes produced different ETags — a silent cache-busting bug that pushed many teams to switch to explicit weak ETags or disable inode-based generation entirely.