Text Compressor

Type or paste text and see what DEFLATE actually does to it: byte counts before and after, a compression ratio, and the compressed bytes rendered as Base64.

What is the Text Compressor?

This is real lossless compression rather than minification. The input is encoded to UTF-8 bytes and run through pako, a JavaScript port of zlib. Gzip and Deflate are genuine here, the same DEFLATE algorithm differing only in the header and checksum wrapped around the data. The third tab, Brotli, is not: the page reuses the Deflate result for it, so the Brotli figure is a placeholder rather than a real Brotli encode.

Key Features

• Real gzip and deflate encoding through pako, a zlib port
• Byte counts for original and compressed plus a ratio and percentage
• Compressed bytes shown as Base64 you can copy or download
• Side-by-side size comparison panel covering the three tabs
• Recompresses as you type, with no upload of the text

Common Use Cases

• Estimating how much gzip will shrink a chunk of JSON before you ship it
• Showing a class why repeated text compresses far better than random characters
• Comparing two drafts of a config file by their compressed size
• Producing a Base64 gzip blob to paste into a test fixture

How to Use the Text Compressor

1. Replace the Lorem ipsum sample with the text you want to measure.
2. Pick the Gzip or Deflate tab to choose which encoder feeds the readout.
3. Read Original Size, Compressed Size, Space Saved and Ratio in the four cards.
4. Check the Algorithm Comparison row to see all three sizes at once.
5. Copy the Base64 output, or Download it as a .txt file.

Tips for Best Results

• Compare gzip and deflate on the same text: the gap is only the header and checksum
• Short inputs often grow, because the format's own overhead outweighs any pattern found
• Repetitive text compresses dramatically while already-compressed or random data barely moves
• The Base64 output is about a third larger than the compressed bytes it encodes

Why Use WiserWork's Text Compressor?

Most people never see the numbers behind the gzip their server performs automatically, and watching the ratio move as you edit the text is the fastest way to build intuition for it. The measurement is honest: the sizes shown are real compressed byte lengths from pako, not an estimate. The Brotli tab is the exception, and currently stands in for the deflate result.

Who Uses the Text Compressor?

Developers sizing an API payload use it to check whether a change is worth the bandwidth. Students and teachers use it to demonstrate why entropy matters, and anyone curious why a text file shrinks by ninety percent while a JPG shrinks by nothing can see the answer in a few keystrokes.

Frequently Asked Questions

Is this real compression or just whitespace removal?

Real compression. The text is encoded to UTF-8 bytes and passed through pako's gzip and deflate implementations, which are ports of zlib, so the byte counts are genuine.

Is the Brotli tab really Brotli?

No. The page reuses the deflate result for the Brotli tab, so its size and output match Deflate exactly. Treat that column as a placeholder, not a measurement.

What is the difference between gzip and deflate here?

The same DEFLATE compressed stream, wrapped differently. Gzip adds a ten-byte header and a CRC32 checksum, so it comes out a handful of bytes larger on identical input.

Why is my compressed result bigger than the original?

Very short or already-random input has no repetition to exploit, and the format's header and tables still cost bytes. Compression only pays off once there is redundancy to find.

Why is the Base64 output longer than the compressed size shown?

Base64 encodes three bytes as four printable characters, adding about 33 percent. The size cards report raw compressed bytes; the text box shows a safe-to-paste representation of them.

Can I decompress something with this tool?

No, it only compresses. Reading a Base64 gzip blob back requires a decoder elsewhere, such as a gzip library called from your own code.

Does the download give me a real .gz file?

No. The download is a .txt file containing the Base64 text rather than the raw binary stream, so it will not open in an archive utility.

Is there a size limit on the input?

No fixed limit, but the Base64 step passes the compressed bytes through a function argument list, which can fail on very large inputs. Work in chunks if a big block produces nothing.

Does my text leave the browser?

No. pako runs as JavaScript in the page, so the compression happens on your own machine and the text is never transmitted anywhere.

Will these numbers match what my web server reports?

Closely, for gzip. Servers usually compress at a similar level, though a different setting or a Brotli-capable server will produce somewhat different figures.

Compression rewards repetition, and a few minutes with this tool makes that concrete: prose halves, JSON often does better, and random data refuses to budge. Just read the Brotli tab as deflate in disguise.