What gzip compression actually does
Gzip wraps the DEFLATE algorithm, which combines two ideas. The first is LZ77, a sliding window matcher: when the compressor meets a run of bytes it has seen recently, it emits a short back-reference saying how far back and how long instead of the bytes themselves. The second is Huffman coding, which then assigns shorter bit patterns to the symbols that occur most often and longer ones to rare symbols.
This is why compression ratio depends so heavily on what the input looks like rather than how large it is. Text with repeated structure compresses dramatically: JSON with the same keys on every record, HTML with repeated tags, a log file with a recurring prefix. English prose typically compresses to around a third of its size. Data that already has high entropy, such as an encrypted blob, a JPEG, or a random string, compresses to nothing or slightly worse than nothing, because the format adds a header and there are no repeats to exploit.
This tool uses the browser's built-in CompressionStream and DecompressionStream with the gzip format, so it is the same implementation your browser uses for HTTP content encoding rather than a JavaScript reimplementation.
Why the output is base64, and what that costs
Gzip output is arbitrary binary, including bytes that are not valid text in any encoding. To display it, copy it and paste it into a field, it has to be converted into printable characters, and base64 is the standard way to do that: it maps every three bytes onto four characters from a 64-symbol alphabet.
That expansion is a flat one third, which changes the arithmetic. A block of text that gzips from 1,000 bytes to 400 becomes roughly 536 characters after base64, so the real end-to-end saving is 46 percent rather than 60. The ratio displayed by this tool compares the compressed byte count against the original, so the base64 text you copy is about a third larger than the figure shown.
Short inputs get worse, not better. A gzip stream carries a header and a trailer of roughly eighteen bytes before any data, and there is little to compress in a short string, so a sentence of forty characters typically comes out longer than it went in once base64 is applied. Compression is worth applying from a few hundred bytes upward, and the gain grows with size and repetition.
A concrete example
Take a JSON array of 200 records where every object has the same six keys. The keys alone repeat 1,200 times, and LZ77 replaces almost every repetition after the first with a short back-reference, so a 48 kilobyte file commonly compresses to around 3 to 5 kilobytes, a ratio near 8 percent. After base64 the transportable string is about 4 to 7 kilobytes, still a large saving.
Now take the same size of input filled with random alphanumeric characters. There are no repeated sequences to reference and the byte distribution is flat, so Huffman coding gains nothing either. The compressed result is essentially the same size as the input plus the header, and after base64 it is a third larger than what you started with.
The lesson is to check the ratio rather than assume one. The tool displays the original and compressed byte counts side by side, so if the percentage is near or above 100 there is nothing to gain and the plain text is the better thing to send.
Where compressed text in a string is useful
The common case is storing state somewhere with a size limit. A URL fragment, a query parameter, a QR code payload, a localStorage entry or a hidden form field all have practical caps, and gzip plus base64 lets a sizeable document fit where the raw text would not. Note that for a URL you need base64url or additional percent-encoding, since standard base64 uses + and / which are not safe in every URL position.
It is also a quick way to inspect how compressible a payload is before deciding whether to enable compression on a server or in a build step. If a representative sample compresses to a tenth, enabling gzip or brotli on that endpoint is clearly worthwhile; if it barely moves, the CPU cost is not buying anything.
Two limits are worth stating. Compression is not encryption: anyone can decompress the output, since there is no key involved, so it hides nothing. And because everything runs in the page, very large inputs are limited by available memory rather than by any server-side cap, and nothing you paste is transmitted anywhere.