Which compression method should I use?

LZ-String is optimized for JavaScript strings and works well for short text. Pako (Gzip) is better for larger texts and general-purpose compression.

Is the compressed output smaller?

Yes, especially for repetitive text. LZ-String produces UTF-16 encoded output, and Pako produces standard gzip compressed data.

Can I decompress text compressed elsewhere?

Yes, if the text was compressed with the same method (LZ-String or Pako/gzip), our decompressor will restore it.

Text Compressor — Compress & Decompress Text

Text Compressor / Decompressor

Compress or decompress text using LZ-String or Pako (Gzip), entirely in your browser.

Compression Method

Input Text

Output:

Output will appear here.

What This Tool Does

Long or repetitive text can often be represented far more compactly than its raw character count suggests, which matters if you're trying to squeeze it into a URL, a localStorage key, or anywhere else with tight size limits. This tool compresses text down using one of two real, well-established algorithms, and decompresses it back to the original afterward.

How to Use It

Choose a Compression Method — LZ-String or Pako (Gzip) — enter your text, and click either Compress or Decompress. Whichever method you compressed with is the one you need to select again when decompressing that same output later; the two formats aren't interchangeable, so decompressing LZ-String output with Pako selected (or vice versa) will fail rather than silently produce garbage.

The Formula

LZ-String compression uses the compressToUTF16 function from the real lz-string library, producing a UTF-16 encoded string built for safely storing in places that expect text, like localStorage. Pako compression runs the real gzip algorithm (the same one behind the .gz file format) via the pako library, which outputs raw compressed bytes — this tool then base64-encodes those bytes into text using the browser's native btoa function, since gzip's raw output isn't safe to display or paste as plain text on its own. Decompressing with Pako reverses both steps: base64-decode back to bytes, then ungzip.

A Worked Example

Take a repetitive 59-character string: "Smart Utilities Hub" repeated three times with spaces between. LZ-String compresses that down to 23 characters — well under half the original length, since LZ-String's algorithm is specifically good at spotting and exploiting exactly this kind of repetition. Pako gzip gives a different picture on the same short input: it produces 43 compressed bytes, but once those bytes are base64-encoded into text for display, the result comes out to 60 characters — slightly longer than the original. That's not a bug; gzip carries a small fixed header overhead that a short input can't outweigh, which is exactly why the FAQ's guidance to prefer LZ-String for short text and Pako for longer, larger text holds up in practice, not just in theory.

FAQ

Which compression method should I use?: LZ-String is optimized for JavaScript strings and works well for short text. Pako (Gzip) is better for larger texts and general-purpose compression.
Is the compressed output smaller?: Yes, especially for repetitive text. LZ-String produces UTF-16 encoded output, and Pako produces standard gzip compressed data.
Can I decompress text compressed elsewhere?: Yes, if the text was compressed with the same method (LZ-String or Pako/gzip), our decompressor will restore it.