gzip / deflate / zlib Compress & Decompress

What is gzip compression?#

gzip is the general-purpose lossless text and byte compressor used across the web — backing HTTP’s Content-Encoding: gzip, the .gz files you fetch from servers, and the wire format of countless log shippers. It works by finding repeated byte patterns and replacing them with short references, so text with repetition (source code, JSON, CSV, log lines) shrinks dramatically, while already-compressed or random data (JPEGs, encrypted bytes) barely moves.

This page offers the three related algorithms that get lumped under “gzip” in casual speech, and they differ only in the wrapper around the same DEFLATE core:

• gzip (RFC 1952) — the full package: a header with a magic byte, the compressed payload, and a CRC32 + size trailer. This is what .gz files and HTTP gzip use.
• deflate (RFC 1951) — the raw compressed stream with no wrapper. Smallest output, but no integrity check; some APIs (older Content-Encoding: deflate) expect exactly this.
• zlib (RFC 1950) — a lightweight 2-byte header plus an Adler-32 checksum, in between the other two.

Because compressed output is binary, the tool renders it as Base64 or Hex text so you can copy it, paste it into JSON, or pipe it elsewhere. Decompress does the reverse: it reads Base64 or Hex and hands back the original UTF-8 text.

How to use it#

1. Pick the algorithm in the toolbar: gzip, deflate, or zlib.
2. Pick the direction: Compress (text in → Base64/Hex out) or Decompress (Base64/Hex in → text out).
3. Pick the output encoding: Base64 or Hex (in decompress mode this selector is locked, since the tool detects the encoding automatically).
4. Paste into the Input pane on the left; the input size is shown in its header. The result fills the Output pane, with its size in the header too.
5. After a compression, the before/after bar appears, showing how much the payload grew or shrank. Use Copy to take the result, or Download to save it as a .gz file. Sample loads a typical log line; Clear resets everything.

Key features#

• Three algorithms, one control. Switch between gzip, deflate, and zlib to see exactly how the wrapper overhead changes the output size for the same input.
• Honest size comparison. The before/after bar shows the real byte counts and the signed percentage change — including the case where compression makes the payload bigger, which is the single most useful thing to know about gzip.
• Automatic encoding detection on decompress. Paste Base64 or Hex and the tool figures out which one it is, so you do not have to remember.
• Strict UTF-8 on the way back. If the decompressed bytes are not valid UTF-8 (wrong algorithm chosen, truncated payload), the tool says so instead of emitting replacement characters that hide the mistake.
• Runs in your browser. Compression runs locally via a small, lazily loaded library; nothing you paste leaves the page.

Worked example#

Compressing a single short log line — the Sample input 2026-08-06 INFO request handled path=/api/stats status=200 (58 bytes) — with gzip and Base64 output gives:

H4sIAHcNdmoAAzMyMDLTNbDQNTBT8PRz81coSi0sTS0uUchIzEvJSU1RKEgsybDVTyzI1C8uSSwpVgCRpcW2RgYGACs/7EA6AAAA

The before/after bar reveals the counter-intuitive part: those 58 bytes of plain text become 75 bytes once gzipped and Base64-encoded. The input was too short and too random for DEFLATE to find anything to compress, so the gzip header, trailer, and Base64 overhead (about 33%) simply pile on top. This is exactly why gzuing tiny payloads is pointless.

Contrast that with repetitive text. Eight copies of the line transaction_id=txn_00001 status=paid amount=100 currency=usd\n total 488 bytes, and gzip brings them down to 84 bytes — about 17% of the original. That is where compression earns its keep: the more repetition, the deeper the shrink.

Switching the same short log line to deflate drops the output to 57 bytes (no header/trailer) and zlib lands at 63 bytes — handy when you are targeting a specific wire format and need to match the other end exactly.

FAQ#

gzip, deflate, or zlib — which should I pick?#

Match the other side. For .gz files, HTTP Content-Encoding: gzip, and almost every “compressed” API payload, use gzip. Use deflate only when an API specifically documents raw DEFLATE (some legacy Content-Encoding: deflate servers). Use zlib when a library or protocol names it explicitly. When in doubt, gzip is the safe default.

My output is bigger than the input. Is that a bug?#

No — it is how lossless compression works on small or high-entropy input. There is a fixed overhead per stream (header, trailer, the dictionary warm-up), and if the content has little repetition, DEFLATE cannot recoup it. A practical rule: gzip starts winning reliably on payloads of a few hundred bytes or more, especially text with repetition. For tiny values, skip compression.

Decompress tells me the data is not valid UTF-8. What went wrong?#

Usually one of three things: you picked the wrong algorithm (the data was zlib-compressed but you selected gzip, or vice versa), the Base64/Hex got truncated or has stray whitespace in the middle, or the original was binary rather than text. Try the other algorithms in turn, and check that nothing trimmed the pasted payload.

Can this compress images, video, or already-zipped files?#

You can paste anything, but you will rarely gain anything. Formats like JPEG, PNG, MP4, and .zip/.gz are already compressed, so DEFLATE has nothing left to squeeze — the output will be about the same size or slightly larger. gzip is a tool for text and structured data, not a second pass over binary media.