Gzip / Deflate Compress & Decompress

Overview

Compresses text with gzip and decompresses gzipped input using the browser's native Compression Streams API. Compressed output is shown as Base64 together with the original and compressed byte counts and the percentage saved; decompression takes Base64 gzipped data and returns the original text. Everything runs locally through the same algorithm your browser uses for HTTP content encoding.

How It Works

Choose Compress or Decompress. On compress, paste text and press the button: the tool streams the text through a CompressionStream in gzip mode and shows the Base64 of the gzipped bytes, with a line reading original bytes, compressed bytes, and the savings percentage. On decompress, paste the Base64 of a gzip stream, press the button, and the original text appears; corrupt input yields an explicit invalid-data message. Click the output panel to copy.

Step-by-Step Usage Guide

1. Select Compress, paste your text, and press the button to see the Base64 gzip output and savings.
2. Note the original and compressed byte counts; compression works best on repetitive text.
3. Select Decompress, paste Base64 gzip data, and press the button to recover the text.
4. Click the output panel to copy either result.

Technical Specifications & Standards

The implementation delegates entirely to CompressionStream and DecompressionStream, which pipe a Blob through the platform's zlib implementation, so the output is a standards-compliant gzip stream per RFC 1952: a header with the magic bytes 1f 8b, the deflate body per RFC 1951, and a CRC-32 plus length trailer. Support landed in every major browser by late 2023, so this works across current Chrome, Firefox, Safari, and Edge without polyfills. The spec also defines deflate and deflate-raw modes, but this tool only wires up gzip; you cannot produce a bare zlib-wrapped or raw deflate stream here. Two format decisions matter for round-tripping with other tools. The compressed bytes are rendered as Base64, not as a downloadable .gz file, so to test against the gzip command line you must decode the Base64 to binary first. And the savings percentage is measured on the raw byte counts before Base64 inflates the representation by about a third, which is the honest comparison with a server's Content-Encoding but not a prediction of how large the Base64 string itself will be. Decompression expects Base64 input for symmetry; pasting raw binary fails at the decode step.

Targeted Use Cases

• Checking how much a JSON payload or log excerpt would shrink under server gzip.
• Producing gzip fixtures for tests without shelling out to a command-line tool.
• Decompressing a Base64-encoded gzip blob from an API response or a queue message.
• Comparing compression behavior of different text corpora in the same browser.

Notes & Gotchas

• Remember the output is Base64 of the gzip bytes, not a .gz file; decode to binary before comparing with gzip CLI output.
• Do not gzip already-compressed data such as images or zip archives; the percentage will be near zero or negative.
• Measure savings on the byte counts shown, not on the Base64 string length, which is about 33 percent larger.
• Verify the data is Base64 before decompressing; raw binary input fails with an error rather than partial output.

Frequently Asked Questions