What Is LZ-String?
LZ-String is a small JavaScript library that compresses a string into a much shorter, text-safe form. It was built for the browser — its signature use is packing application state into a URL or squeezing large values into localStorage.
The One-Line Definition
LZ-String is an open-source, dependency-free JavaScript compression library (created by pieroxy) that turns any string into a compact, text-safe string using an LZ-based algorithm.
Why Does LZ-String Exist?
The web moves a lot of small strings through channels that were never meant for bulk data: URL query strings, hash fragments, HTTP headers, and the browser’s localStorage (typically capped at around 5 MB per origin). General-purpose compressors like gzip are geared toward files and, until recently, were not readily available in the browser.
LZ-String fills that gap. It is tiny, runs entirely client-side, and — crucially — can emit output in several alphabets so the compressed result is safe to drop directly into a URL, a JSON field, or localStorage without a second encoding step.
How LZ-String Works
LZ-String uses a dictionary-based LZ scheme: as it scans the input it builds a growing dictionary of substrings it has already seen, and replaces repeated substrings with short numeric references. Highly repetitive text — like JSON with recurring keys — compresses dramatically.
Its clever trick is bit packing. JavaScript strings are sequences of 16-bit code units, so LZ-String packs multiple output bits into each character rather than wasting a full byte per symbol. The raw compress() output is the most compact, but those characters can include values that are invalid or fragile in text channels — which is exactly why the encoded variants below exist.
LZ-String is not compatible with gzip, zlib, or DEFLATE. A value compressed with LZ-String can only be decompressed with LZ-String. It is optimised for short strings in the browser, not for interoperable file compression.
The Output Variants (and Which to Use)
This is the part that trips people up. LZ-String ships several compress/decompress pairs that differ only in the output alphabet. They are not interchangeable — you must decompress with the same variant that compressed the data.
| Function pair | Output alphabet | Safe for | Size vs raw |
|---|---|---|---|
| compress / decompress | Raw 16-bit chars | In-memory only — may contain invalid UTF-16; can be mangled by storage/transport | Smallest |
| compressToUTF16 / decompressFromUTF16 | Valid UTF-16 (15 bits/char) | localStorage, sessionStorage, IndexedDB | ≈ +6% |
| compressToBase64 / decompressFromBase64 | A–Z a–z 0–9 + / = | JSON, HTTP headers, general ASCII text | ≈ +33% |
| compressToEncodedURIComponent / … | A–Z a–z 0–9 + - $ | URL query strings & hash fragments (no % escaping) | ≈ +33% |
| compressToUint8Array / … | Raw bytes | Blobs, file downloads, binary channels | Small |
How Much Does It Save?
Savings depend entirely on the input. Long, repetitive text — pretty-printed JSON, HTML, application state with recurring keys — often shrinks by 50–90% even after re-encoding to a text-safe alphabet. Very short or high-entropy input (already-random tokens, tiny strings) can grow, because the dictionary and encoding overhead exceeds what little redundancy there is. LZ-String pays off on payloads of at least a few hundred characters.
LZ-String Is Not Encryption
A compressed string may look scrambled, but it offers no confidentiality. There is no key — anyone can decompress it in milliseconds. If you need to protect data, encrypt it with a real algorithm (AES-GCM, ChaCha20-Poly1305) before compressing.
Where LZ-String Is Used in Practice
Compress or Decompress LZ-String Now
SmartDevBox runs LZ-String entirely in your browser — your data is never sent to a server. Paste a compressed value and the decompressor auto-detects the variant (URL-safe, Base64, UTF-16, or raw) for you. Open LZ-String Compress → or LZ-String Decompress →
Frequently Asked Questions
Is LZ-String the same as gzip?
No. LZ-String is a pure-JavaScript, LZ-based compressor tuned for short strings in the browser. Its output is not compatible with gzip, zlib, or DEFLATE — decompress it with LZ-String.
What is the difference between compressToBase64 and compressToEncodedURIComponent?
Base64 output uses A–Z, a–z, 0–9, + and / with = padding. EncodedURIComponent output is URL-safe: it uses - and $ instead of / and =, so it needs no percent-encoding in a query string. They are not interchangeable — decompress with the matching function.
Why does my LZ-String value fail to decompress?
Almost always a variant mismatch — e.g. the value was produced by compressToBase64 but you are decompressing with the EncodedURIComponent function. SmartDevBox avoids this by trying every variant automatically.
Is LZ-String encryption?
No. It is compression with no key and no confidentiality. Anyone can decompress it. Encrypt sensitive data separately.
Can LZ-String make my string longer?
Yes, for very short or already-random input. The dictionary and text-safe encoding add overhead that only pays off once there is enough redundancy to compress — typically a few hundred characters or more.