Available-Dictionary

The HTTP Available-Dictionary request header signals the client has a Compression dictionary in storage and is ready to decompress responses encoded with the matching dictionary.

Table of Contents

Usage

Compression dictionaries reduce payload size by replacing repeated patterns with references to a shared dictionary. Both parties must have the same dictionary for this to work. The client stores dictionaries from previous responses marked with the Use-As-Dictionary header. When making future requests, the client includes Available-Dictionary to declare which dictionaries the client holds.

The header value is a Structured Field Byte Sequence containing the SHA-256 hash of the available dictionary encoded in Base64. The server checks the hash against dictionaries registered for the request path. When a match exists, the server compresses the response using the referenced dictionary and marks the encoding with Content-Encoding: dcb (dictionary Brotli) or dcz (dictionary Zstandard).

The compression dictionary transport framework defines the header format, negotiation flow, and security requirements. The mechanism operates only in secure contexts (HTTPS).

Example

The client sends Available-Dictionary with the SHA-256 hash of a previously stored dictionary. The hash identifies the dictionary the client holds for the requested resource.

Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

The server matches the hash, compresses the response using the referenced dictionary, and indicates the encoding method with the dcb or dcz value in Content-Encoding.

GET /api/data HTTP/1.1
Host: example.re
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

HTTP/1.1 200 OK
Content-Encoding: dcb
Content-Length: 1456

How the match is made

The value is a structured-field byte sequence, which is why the SHA-256 hash arrives wrapped in colons rather than bare. The colons are syntax, not decoration, and a parser treating them as part of the value fails the lookup. A request carries at most one Available-Dictionary, naming the single best dictionary the client holds, never a list.

Matching runs on the server-declared pattern with firm rules: the dictionary and the resource share an origin, the URL pattern contains no regular expressions, and matching operates on the percent-encoded path. Freshness gates everything: a dictionary past its cache lifetime stops being offered unless stale serving is allowed, so the Cache-Control policy on the dictionary resource directly moves the hit rate.

The compressed formats defend themselves. Both dcb and dcz bodies embed the dictionary hash after a magic number, so a decoder holding a different dictionary rejects the response rather than emitting garbage. Early material names the encodings br-d and zstd-d, renamed before standardization.

Chrome ships the mechanism by default, with Firefox and Safari holding positive standards positions and no shipped support. Google Search compresses result pages against a purpose-built dictionary, reporting HTML payloads down 23% against plain Brotli. Cloudflare passes the headers and encodings through and varies its cache on them, leaving compression to the origin. Enterprises intercepting TLS get a dedicated Chrome policy to switch the feature off, since middleboxes inspecting traffic choke on content codings they never learned.

See also

Last updated: August 17, 2026