Gzip Text Compressor
Compress text to gzip and decompress gzip back to text, right in your browser.
Drag & drop a .gz file here, or click to browse
A .gz file is unpacked; anything else is compressed. Stays on your device.
Gzip header & trailer
How it works
This page compresses and decompresses real gzip streams (RFC 1952, wrapping DEFLATE from
RFC 1951) using the browser's built-in CompressionStream and
DecompressionStream APIs. Type or paste text and the gzip bytes are produced
as you type, shown as Base64 (the familiar H4sI… string) or as lowercase hex.
Switch to Decompress and paste a Base64 or hex gzip blob to get the original text back.
Below the stats you get the header and trailer fields read straight out of the stream: the
1f 8b magic number, the compression method, MTIME, the OS byte, and the
trailing CRC-32 and ISIZE that gzip stores little-endian. That trailer is the quickest way
to check a stream by hand: the CRC-32 of 123456789 is 0xCBF43926,
so a correct gzip of that string always ends with the bytes
26 39 f4 cb 09 00 00 00.
Everything runs locally in JavaScript — no upload, no server, no signup — so payloads, tokens and API responses stay on your device. Base64 adds about 33% overhead, so for very short inputs the encoded result is longer than the text you started with; the stats line reports the raw gzip byte count too, so you can see the real saving.
Frequently asked questions
Is my text uploaded anywhere when I gzip it?
No. The compression runs in your own browser through the built-in CompressionStream and DecompressionStream APIs, the same gzip implementation your browser uses for network responses. Nothing is sent to a server, so tokens, payloads and API responses stay on your device even if you close the tab.
Why does gzip output start with H4sI?
Every gzip stream begins with the bytes 1f 8b 08 from RFC 1952: the 1f 8b magic number plus compression method 8 (DEFLATE). Encode those three bytes as Base64 and you always get the characters H4sI, which is why nearly every Base64 gzip blob starts that way. If your data does not start with H4sI it is probably raw DEFLATE or zlib rather than gzip.
How can I check the gzip output is correct?
Look at the trailer. RFC 1952 stores a CRC-32 of the original data and the uncompressed length (ISIZE) as little-endian 32-bit values in the last 8 bytes, and this page decodes both for you. The CRC-32 of the string 123456789 is 0xCBF43926, so gzipping it here ends with the hex bytes 2639f4cb09000000, which matches the standard check value.