Accept-Encoding Explained: Encoded vs Decoded Body Size

Accept-Encoding negotiation produced a 30,038-byte gzip body and a 145,043-byte identity body in a ColdProxy HTML test, with equal decoded length and hash.

Those counts came from two measurement stages: the encoded stream received by the client and the decoded HTML handed to the application.

Key takeaways

• Log the requested coding list and the returned coding as separate fields.
• The identity, gzip, and Brotli variants had very different encoded sizes and shared one decoded length and hash.
• Gzip finished 1,087 bytes smaller than Brotli in this snapshot, so measure the response directly.
• Record encoded size, decoded size, and the collection stage together. Use separate evidence for packet traffic or plan billing.

What does Accept-Encoding negotiate?

Accept-Encoding is an HTTP field used for content negotiation. A content coding is a reversible transformation, such as gzip, applied to a representation before delivery. The HTTP Semantics standard states, "When sent by a user agent in a request, Accept-Encoding indicates the content codings acceptable in a response."

For the response-body exchange in our test, the client sent Accept-Encoding with one preferred coding. The server then returned Content-Encoding when it applied gzip or Brotli. The identity condition requested the representation without content coding.

Quality values can rank several acceptable choices. For example, a client may prefer Brotli, accept gzip with a lower weight, and still allow identity. The server chooses an available representation under HTTP negotiation rules. Confirm that choice from the response received by the measuring client.

The fields answer separate questions:

• Accept-Encoding: which response codings can this client decode?
• Content-Encoding: which coding was applied to this representation?
• Identity: was the response body delivered without a content coding?

These roles are scoped to the response flow described here. HTTP permits the same field names in other message directions, so request-versus-response shorthand should stay tied to the exchange being measured.

How much did Accept-Encoding change the ColdProxy response?

On August 25, 2026, we requested HTML from the ColdProxy public IP lookup page three times over HTTP/1.1. Each request used one Accept-Encoding condition: identity, gzip, or Brotli. We recorded status, selected coding, encoded and decoded body counts, decoded hashes, and the expected page heading.

The public page returned HTTP 200 in every condition. Its encoded response-body counts were:

• Identity: 145,043 bytes
• Gzip: 30,038 bytes
• Brotli: 31,125 bytes

All three variants decoded to 145,043 bytes and shared the same decoded SHA-256 hash. Matching both values gives strong evidence that the compared decoded bodies agreed. We saved only the length and hash checks. Response bodies were discarded after measurement.

Against identity, gzip reduced the encoded body count by 79.29% and Brotli reduced it by 78.54%. The gzip representation was 1,087 bytes smaller than the Brotli representation for this response.

Here, encoded response-body bytes means the body octets collected by the HTTP client after transfer framing. That count excludes response headers, HTTP/1.1 chunk framing, TLS records, TCP/IP headers, retransmissions, and other packet overhead. Total network traffic requires a packet-level measurement.

The requests fetched public HTML without calling the page's public-IP lookup. We retained protocol fields, counts, and hashes. Page bodies and network-identifying values never entered the saved observation. The result covers one public page at one time, with the server settings and resource version available during that request set.

Why do encoded and decoded size disagree?

Compression represents repeated data with fewer octets. A recipient reverses that coding before a browser parses HTML or an application consumes the body. The MDN guide to HTTP compression describes representation compression as end to end: the message body stays encoded until it reaches the client, which then decodes it.

Automatic decompression moves the byte counter from the received stream to the representation exposed to application code.

Consider a dashboard comparing a direct request with a proxied request. One test records about 30 KB from the gzip stream. Another records about 145 KB after decoding. The chart appears to show a route difference even though its collectors sampled different stages.

The two-counter rule prevents that mistake: record the encoded response-body count before decompression and the decoded count after it. Label both values with their measurement stage and selected Content-Encoding.

Choose the measurement from the question:

• Compression or response-transfer comparison: use encoded response-body bytes.
• Parser input, decoded storage, or application memory: use decoded bytes.
• Full network cost: use packet capture or equivalent transport-level telemetry.
• Commercial usage: use the service's published buying model and terms.

Track body size, response time, capacity, availability, and request success with separate measurements. The ColdProxy guide to latency, bandwidth, and uptime explains the network metrics.

Does Brotli always produce the smallest body?

Encoder settings, input bytes, and server policy determine the final size. Brotli is efficient for many web-text workloads. Measure the particular response before comparing codecs.

Our snapshot showed the practical effect. Gzip produced the smaller encoded body by 1,087 bytes. Encoder settings were outside the observation, leaving the ordering unexplained. A repeat against another page, a changed asset, or a different server configuration may reverse it.

The broader web also uses a mix of codings. The HTTP Archive 2024 Web Almanac Markup chapter reports Brotli on 36% of desktop and 37% of mobile HTML documents, gzip on 53% of desktop and 52% of mobile documents, and 11% uncompressed in both sets. Those figures describe its 2024 dataset.

Retest after content or delivery settings change, then compare matched samples across several runs.

What should you log in an Accept-Encoding test?

For each response, record enough context to reproduce the result:

• Target URL and timestamp
• Requested Accept-Encoding value
• Response status and HTTP version
• Returned Content-Encoding value, or identity when absent
• Encoded response-body byte count
• Decoded byte count
• Decoded-content hash when equivalence matters
• Content-Length when present
• Retry, timeout, and truncation outcomes

For route comparisons, apply the two-counter rule and include a non-sensitive route and session label. Keep credentials, public IPs, and precise location data outside the measurement log. Hold the target, headers, client, and byte-counter position steady before attributing a size change to the route.

An absent Content-Length is a result to record. Streaming or transfer framing can leave that header unavailable even when the client receives a complete body. Count the bytes actually observed at the chosen layer and keep the completion status beside the value.

Hashing adds a useful equality check. If the decoded hashes diverge, investigate content changes, dynamic markup, truncation, or transformation before comparing compression ratios. If the hashes and lengths agree, the size comparison has a stronger common-content basis.

How do caches separate compressed variants?

Identity, gzip, and Brotli can represent the same resource with different encoded bytes. A cache therefore needs the request field that influenced representation selection. RFC 9110 defines Vary as a signal that the listed request fields affected the selected representation. Every response in our observation included Vary: Accept-Encoding.

That field lets a cache distinguish variants selected for different client capabilities. It belongs in the same diagnostic record as the request preference and the returned coding. If a response passes through an intermediary, use the headers that arrived at the client as evidence. Origin configuration and previous requests describe other states.

Variant selection and freshness solve different cache questions. Vary: Accept-Encoding identifies the negotiation dimension. Cache directives control reuse. The ColdProxy article on Cache-Control no-store for live IP checks covers freshness for pages whose runtime result should be requested again.

Does a proxy change Accept-Encoding?

A proxy preserves the HTTP field semantics. The client still advertises acceptable response codings, and the received response still reports the selected coding. Representation compression normally spans the end-to-end exchange described by MDN.

An intermediary may transform a representation when HTTP rules and message directives allow it. That possibility makes the received response the relevant evidence. Measure the headers and bytes at the same client boundary for direct and proxied runs. Then check decoded equality before blaming a route for a different size.

Use the buying models on ColdProxy's pricing page when evaluating commercial metering.

How should you retest the result?

Start with one URL and one client. Run identity, gzip, and Brotli requests close together. Save only the non-sensitive protocol fields, counts, and hashes needed for comparison. Confirm successful completion and a common decoded result before calculating reductions.

Next, repeat the set. Dynamic HTML can change between requests, and delivery settings can change over time. A sequence of matched-hash samples provides a better basis than a single measurement. If the results differ, inspect content freshness, selected coding, and byte-counter position first.

For a ColdProxy-owned public target, that public IP lookup page provides the HTML surface used in this run. Its runtime result area contains sensitive network information, so exclude those values from compression artifacts and screenshots. The compression check only needs the public document response.

Frequently Asked Questions

Which roles do Accept-Encoding and Content-Encoding have?

For the response-body flow, the client sends Accept-Encoding to list acceptable codings. The server's response uses Content-Encoding to identify the applied coding. During diagnosis, log both fields from the same exchange: the request records preference, and the response confirms the representation received by that client.

Can Brotli be larger than gzip?

Yes. Resource content, encoder quality, server policy, and implementation choices affect the final size. Our controlled page check placed gzip slightly ahead. Repeat the test against the exact resource and preserve the decoded hash, which reveals a content change before the compression comparison.

Can compressed and identity responses contain equivalent HTML?

Yes. Content coding changes the delivered representation, then the client decodes it for use. Compare decoded length and a strong content hash across conditions. Agreement on both gives practical evidence of equivalent decoded output. Each encoded response can still have a different body count.

Which byte count should I use for a proxy test?

Use encoded response-body bytes for compression and response-transfer comparisons. Use decoded bytes for application input. Use packet telemetry for full network traffic, and consult published plan terms for billing. Whichever count you choose, store the collection stage, selected coding, timestamp, and completion status beside it.