HTTP compression: gzip and Brotli

What it means

Separate what the content is from how its bytes are coded. The media type describes the content to interpret after decoding; the content coding describes the transformation applied to its bytes. Compressed HTML is still HTML after decoding.

This example compares encoded and decoded body sizes. It does not compress content or decide which coding a server should send.

Try it

Example: start with Decoded representation size (KiB) = 100 and Encoded body size (KiB) = 30. Change only Encoded body size (KiB) to 90, then choose Compare with baseline. Inspect how the result changes and why. No file is compressed and no request is sent. The initial example remains readable without JavaScript; editing and comparison require JavaScript.

70.0% modeled byte reduction. 100 KiB decoded versus 30 KiB transferred body; size ratio does not establish encode/decode CPU cost or which Content-Encoding was used.

Keep Decoded representation size (KiB) at 100. This isolates the change in encoded body size; no coding selection or server negotiation is being varied.

Reset restores Decoded representation size to 100 KiB and Encoded body size to 30 KiB, clears input errors and removes the comparison. It leaves FAQ answers and the About this model disclosure open or closed as you chose them.

How it works

A content coding transforms the representation's bytes before delivery. For a single applied coding, the receiver decodes those bytes to recover the original representation. Decoder support and accurate metadata therefore matter independently of how small the body is: a response labeled br must contain Brotli-coded bytes, not gzip bytes of a similar length.

For a synthetic request containing Accept-Encoding: br, gzip, both codings are advertised as acceptable. That does not require the server to select Brotli or establish that Brotli will produce fewer bytes. If the server selects Brotli, it labels the response Content-Encoding: br. A coding explicitly excluded by the request must not be treated as accepted.

When representation selection depends on Accept-Encoding, Vary: Accept-Encoding identifies that request field as relevant to cache matching. The intermediate condition is not merely “same URL”: a stored response must also match the applicable variation rules. This matters because a previously stored br response is not suitable solely because a later request uses the same URL. Vary does not itself make an otherwise uncacheable response reusable; other storage and reuse rules still apply.

RFC 9841 describes Shared Brotli extensions. That does not establish that accepting ordinary br makes an arbitrary shared dictionary available. This comparison does not configure or exercise shared-dictionary delivery.

The size calculation addresses a different question: how much smaller is the supplied encoded body than its decoded representation? It contains no encoding or decoding work and no timing evidence, so a reduction in body bytes cannot establish a reduction in total latency.

Worked example

Synthetic baseline: Decoded representation size (KiB) = 100; Encoded body size (KiB) = 30. These are teaching inputs, not a captured response.

The difference is 100 − 30 = 70 KiB. Dividing that difference by the decoded size gives 70/100 = 0.70, displayed as 70.0% modeled byte reduction.

Equivalently, the formula is 100 × (1 − encoded body size / decoded representation size). The denominator matters: this means 70% fewer body bytes relative to the decoded size, not a 70% reduction in page load time.

What changes when the condition changes

Change only Encoded body size (KiB) from 30 to 90, leaving Decoded representation size (KiB) at 100.

10.0% modeled byte reduction. 100 KiB decoded versus 90 KiB transferred body; size ratio does not establish encode/decode CPU cost or which Content-Encoding was used.

The size difference is now 10 KiB rather than 70 KiB, so the modeled reduction falls by 60 percentage points. This demonstrates sensitivity to encoded length—not the effect of switching from Brotli to gzip, because the example has not run either encoder.

In practice

For a read-only comparison on a site you own or are authorized to test, use a permitted response capture or test environment. Compare the same decoded content under stated client and test conditions. First confirm what your inspection tool calls “size”: this example needs the encoded body size and decoded representation size, not a whole-connection total.

Record the request's Accept-Encoding, the response's Content-Encoding, any relevant Vary fields and both body sizes. The expected observation is that the declared coding agrees with the delivered bytes and is acceptable under the request's negotiation conditions. When selection depends on Accept-Encoding, also inspect how that variation is represented for caches. Measure encoding and decoding costs separately from byte counts.

Stop if the coding label conflicts with the body, the request excludes the delivered coding, or the reported sizes cannot be distinguished as encoded versus decoded. Resolve that discrepancy before treating the comparison as evidence for a delivery decision. A valid percentage in this local example cannot verify any of those real-response conditions.

This is a read-only assessment, not a server-configuration procedure. Do not use its percentage alone as justification to change production compression or caching settings.

Limits and unknowns

The example evaluates two supplied sizes only. It does not read a file, run gzip or Brotli, send a request, inspect a server or validate a cache. Actual coding, negotiation success, processing cost and delivery latency therefore remain unknown.

Both fields have a supported range of 1–100,000 KiB. Invalid entries replace the calculated outcome with an error until you correct the input or use Reset; the scene does not keep showing a result from an earlier valid input.

A negative reduction is different from an invalid input. For 100 KiB decoded and 110 KiB encoded, the result is -10.0% modeled byte reduction: the encoded body is 10% larger than the decoded representation. The model does not clamp that result to zero. Its inputs describe body sizes, not all HTTP headers or connection overhead.

What to carry forward

Treat client compatibility and correct representation labeling as prerequisites, then compare byte and processing costs for your content. A smaller encoded body establishes fewer body bytes relative to the decoded size. It does not, by itself, establish a faster response or a universal gzip-versus-Brotli winner.