Gzip Compress/Decompress

Gzip and deflate are the two compression formats behind nearly every "Content-Encoding: gzip" response header on the web — they find repeated patterns in text and replace them with shorter references, which is why highly repetitive data (JSON with many similar objects, verbose XML, plain-text logs) can shrink to a fraction of its original size. Gzip wraps deflate's compressed data with a small header and checksum; deflate is the raw compressed stream without that wrapper — picking the wrong one is the most common reason a decompression fails against otherwise-valid compressed bytes.

Since compressed output is arbitrary binary data, this tool Base64-encodes it for display and copy-paste — decompression expects that same Base64 text back, not raw bytes. This is genuinely useful for inspecting an API response you've captured as gzipped bytes (from browser dev tools or a proxy log) without spinning up a script, or for sanity-checking how much a payload would actually shrink before implementing compression in a real service.

• •Match the format exactly — data compressed as gzip won't decompress as deflate and vice versa, even though both use the same underlying algorithm, because gzip adds its own header and checksum bytes.
• •Compression has overhead — for very small inputs (a few dozen bytes), the compressed output can end up larger than the original, since the format's header outweighs any savings from finding repeated patterns.
• •This tool works on text; for inspecting a gzipped file or binary API response, first get its bytes as Base64 (e.g. from browser dev tools' response payload) before pasting into decompress mode.
• •Compression ratio scales with repetition — highly structured, repetitive data (JSON arrays of similar objects) compresses far better than already-compressed or high-entropy data like images or random tokens.