MundoKit

Compression dictionary header checker

Paste dictionary response headers and the matching resource exchange. Choose an RFC-only or browser profile to inspect syntax and declared matching conditions.

Inspect pasted headers locally. This tool does not contact a server or test compression.

How it works

RFC 9842 defines Use-As-Dictionary as a Structured Field Dictionary, Available-Dictionary as a SHA-256 Byte Sequence, and Dictionary-ID as a String. The checker parses those types and compares the declared URL, destination, freshness, identifier, encoding and Vary conditions. Findings are counted without rounding.

The browser profile checks Fetch destination and declared response readability. The RFC-only profile models a client without request destinations. Neither profile claims support in a particular browser release. Native URLPattern is used when available. The fallback handles a conservative subset of absolute path literals and single * wildcards. Dot segments, percent escapes, modifiers and other unsupported syntax are marked unassessed. Content-Encoding lists and repeated field lines are checked for every dictionary coding. The native parser rejects patterns with regular-expression groups.

Each header block is limited to 100,000 UTF-8 bytes and 1,000 lines. URLs are limited to 8,192 characters. These are local application limits. This single-dictionary inspection does not select between multiple stored dictionaries, verify the actual dictionary hash, determine freshness from cache headers, or perform a live CORS check.

Worked examples

A matching script dictionary

Use match="/app/*", match-dest=("script") and id="v1". Request /app/main.js from the same HTTPS origin with the example 32-byte hash, Dictionary-ID: "v1", and Accept-Encoding: dcb. A dcb response with both Vary fields, a fresh dictionary and readable responses yields 0 negotiation issues.

A missing identifier echo

Keep that exchange but remove Dictionary-ID from the request. The stored id is nonempty, so the checker reports 1 negotiation issue.

Frequently asked questions

Is Available-Dictionary a hexadecimal hash?
No. It is a Structured Field Byte Sequence: base64 between colons, decoding to the 32 bytes of SHA-256. This tool checks the length and syntax, not the dictionary contents.
How long may Dictionary-ID be?
RFC 9842 permits up to 1,024 decoded characters. It must match the stored nonempty id when the dictionary is advertised.
What does an empty match-dest list mean?
It matches every destination. A client without destination support ignores this restriction. The browser profile applies nonempty destination lists.
Can a dictionary apply to another origin?
The dictionary and resource must share an origin. Browser context readability adds a separate check: same-origin readability or a successful CORS check for both responses.
Does a clean report prove that compression will work?
No. Storage, hash verification, freshness evidence, browser implementation, cache partitioning and actual compression remain untested. Unknown conditions stay visible.

Sources

Last reviewed 2026-11-14; next review due by 2027-02-12. The method is written out above so you can check our math.