Those two bytes - 1F 8B - that turn up where you least expect them
Open a captured API response, scroll through a log bundle, or crack open a backup someone left on a shared drive, and sooner or later you hit it: a wall of unreadable bytes beginning with 1f 8b. That little signature is gzip waving at you. This page hands the text back, and it does the whole thing inside your tab - nothing travels to a server.
You paste. It expands. That is the entire arrangement.
Why so much of the web shows up squeezed
Text repeats itself. Constantly. The same HTML tags, the same JSON keys, the same log timestamps marching down the page. Gzip spots those patterns and records them once instead of a thousand times. Underneath, the DEFLATE method pairs LZ77 - which swaps repeated chunks for short back-references - with Huffman coding, which hands the most common bytes the shortest codes. For ordinary text that pairing usually trims size by 60 to 90 percent.
Servers lean on this every second of the day. A response goes out carrying Content-Encoding: gzip, the browser quietly unpacks it, and nobody watching the page ever notices. Less bandwidth, faster first paint, smaller bills.
There is a catch, though. There always is. Anything already compressed gains nothing here - JPEGs, MP4s, ZIP files, most binaries. Run gzip over them and you can finish a few bytes larger, because you have bolted a header onto data that had no slack left to give.
That layout earns its keep the moment a decompression fails. No leading 1F 8B? You are likely holding raw zlib, or a Base64 string that never decoded. A complaint about the CRC? The bytes arrived damaged or cut short. The error this tool surfaces tends to point straight at one of those.
Moments where pasting bytes beats the terminal
A handful of situations where this page quietly wins:
- Reading a response you captured mid-flight
Your proxy logged a gzipped JSON body as Base64. Drop it in, read the payload, carry on - no curl gymnastics required.
- Confirming compression is even happening
The byte counts and ratio tell you at a glance whether the server is really shipping something smaller, or just claiming to.
- Peeking inside a stray .gz
A log fragment, a config export, a chunk of a backup - when you only want to see what is in there before committing to a full extract.
With the Base64 and Hex paths especially, it helps to keep the encoding and the compression as two separate layers in your head. If a string refuses to expand here, decode it first with the Base64 decoder, or run it through Base64 to Hex to check you are actually holding gzip bytes and not a double-wrapped blob.
Gzip is not the only stream you will run into
Its close cousins catch people out. Raw zlib uses the same DEFLATE core but wraps it in a slim 2-byte header instead of gzip's full structure - feed one to the other and you get an error, nothing more. When that happens, the zlib decompressor is the right door. Brotli and LZMA/7z are different algorithms altogether and will not open here at all.
If you are weighing formats, or just curious what else lives nearby, the compression toolset keeps the decoders in one spot.
One limit worth saying out loud: this is a decompressor, not a compressor. It reads gzip; it does not make it. And since everything runs inside the browser tab, genuinely huge files lean on your own device's memory rather than a server's - fine for logs and payloads, far less fun for multi-gigabyte archives.
