Content-Type and Content-Encoding: JSON can be compressed

Give the headers different jobs

Content-Type describes the media type of the representation. Content-Encoding describes content codings applied to it.

A JSON response compressed with Gzip remains application/json after decoding; it is not automatically application/gzip as a media type.

Content-Type: application/json
Content-Encoding: gzip
Decoded body: {"ok":true}

Distinguish a downloadable archive

A downloadable Gzip file can legitimately use application/gzip when the compressed container is the intended artifact.

That differs from an HTTP JSON response compressed for transfer. Decide what the user or client is supposed to receive after transport decoding.

Avoid decompressing twice

Browser fetch normally exposes a decoded response body after HTTP content decoding. The remaining header does not mean the exposed text is still compressed.

Check the client library contract before piping the body into another Gzip decoder. The site's Gzip tool expects Base64-wrapped Gzip bytes.

Vary negotiated responses appropriately

A server selecting a coding according to Accept-Encoding needs caching behavior that keeps variants consistent, commonly using Vary.

Inspect raw transfer bytes only with a client mode that actually preserves them. Decoded text length is not necessarily the Content-Length on the wire.