Convert Any File to LZ Online (Building lzip's Integrity-First Container)

What Actually Gets Written Into a Fresh .LZ File

Lzip is a compression format and command-line tool created by Antonio Diaz Diaz and first released in 2008, documented today in a published IETF Internet-Draft that also formally registers "application/lzip" as a media type. Building a new .lz file starts with LZMA compression — the same core algorithm 7-Zip's default 7z format and the xz format both use — but lzip wraps that compressed data in its own specific container rather than reusing either of theirs. The file opens with a fixed four-byte signature, 0x4C 0x5A 0x49 0x50, spelling "LZIP" in ASCII, followed by a version byte and a single coded byte recording the dictionary size the compressor chose, then the LZMA-compressed data itself.

What comes after the compressed data is what actually distinguishes a fresh lzip file from most other compressed formats: a trailer holding three separate, independently checkable values — a CRC32 of the original uncompressed data, the exact byte size of that original data, and the size of the compressed member itself. Lzip's own documentation calls this a "3-factor integrity check," and it's a deliberate design choice built into every single .lz file the format produces, not an optional feature that has to be turned on.

Why Lzip's Documentation Makes a Specific Case Against XZ

Lzip's project documentation includes a page titled "Xz format inadequate for long-term archiving," which argues its case with specific, named technical objections rather than general preference. It states that none of the many length fields inside an xz container are protected by a checksum, that xz's variable-length integer encoding can suffer what the page calls a "double framing error" where one corrupted byte changes both a field's value and how many bytes make up that field, and that xz's own integrity check is optional per stream rather than mandatory. The same documentation states that lzip, by contrast, protects all of its length fields and requires no optional check types to begin with — every .lz file a fresh conversion produces carries that same built-in, non-optional protection.

That difference matters most for exactly the kind of file this conversion is meant to produce: something built once and expected to remain verifiably intact well into the future, without needing anyone to remember to enable an integrity option that a different format might have left off by default. Lzip compresses one continuous stream at a time, with no built-in concept of multiple files, so converting several files into a single .lz archive means bundling them with tar first, producing the combined ".tar.lz" extension — the exact pattern GNU Automake documents through its own "dist-lzip" option for source releases.

What Producing a Fresh LZ Archive Actually Gains and Costs

• Gain — a built-in 3-factor integrity check on every file: CRC32, original data size, and compressed member size are all recorded and independently verifiable, not an optional feature that has to be enabled.
• Gain — LZMA-based compression, generally tighter than DEFLATE: lzip's much larger dictionary window than gzip's fixed 32 KiB typically produces a smaller result on the same data.
• Gain — access to lziprecover: a dedicated recovery tool built specifically around lzip's own trailer format, meant to pull back as much data as possible from a damaged .lz file.
• Lose — broad, plug-and-play software support: most mainstream archive tools handle ZIP or 7z directly, while opening or creating .lz generally needs a specific package or plugin installed first.
• Lose — compression speed: lzip's LZMA-based compression runs noticeably slower than gzip's DEFLATE at comparable settings, according to lzip's own published benchmark data.
• Lose — native multi-file structure: unlike ZIP, a plain .lz file holds one compressed stream only; multiple files require tar first, adding a step ZIP doesn't need.

Where a Freshly Built .LZ File Actually Opens

GNU tar has supported lzip transparently since version 1.23 through its own --lzip option, and GNOME's Archive Manager opens the format directly on Linux desktops without any extra configuration. Real, documented projects that already publish files this way include the IANA Time Zone Database and the Linux-libre kernel project, both of which distribute some releases as .lz archives, which is useful context for knowing the format genuinely sees production use rather than being a niche curiosity.

Windows and macOS need more setup. 7-Zip's standard build does not include native lzip support at all; creating or opening .lz files with it requires the separate Lzip7z plugin, distributed independently of the main project. WinRAR's own documented supported-format list — RAR, ZIP, and extraction support for 7z, ISO, JAR, BZ2, GZ, TAR, and ARJ among others — doesn't include lzip anywhere on it. Bandizip is one of the few mainstream Windows archive managers whose own documentation lists direct lzip support without a separate plugin, and on macOS, Homebrew distributes lzip itself as an installable command-line package for anyone who needs to build or open .lz files there.

That narrower support picture is exactly why a freshly built .lz file is worth thinking about before sending it somewhere. Sharing one with a Linux-based collaborator whose distribution already ships lzip in its package repositories, or with a GNU-affiliated project that already documents lzip support in its own build tooling, involves no friction at all. Sending the same file to someone whose only archive tool is a stock, unmodified copy of 7-Zip or WinRAR on Windows means they'll need to track down and install a separate plugin or program before they can even see what's inside.

Real Reasons People Actually Choose to Build an LZ File

The most consistent documented reason is long-term archival integrity specifically — projects that care about a file remaining verifiably uncorrupted years or decades later point directly to lzip's own stated design goals and its explicit, published criticism of xz's less-protected length fields as the deciding factor, rather than raw compression speed or the widest possible software compatibility.

A second real pattern shows up in GNU and Linux-affiliated release pipelines: Automake's documented "dist-lzip" option exists precisely so build systems already following the GNU Coding Standards can emit an .lz-compressed source tarball as one of their standard release artifacts, alongside the far more common .tar.gz, without needing any custom scripting to make lzip part of the release process.

A third pattern involves data that genuinely needs a recovery path if something goes wrong later — lziprecover's design, built specifically around lzip's own three-factor trailer, gives a documented, tool-supported way to pull back as much of a damaged .lz file's contents as possible, a capability that isn't tied the same way to formats using a single whole-file checksum instead of lzip's three separate checks.

A Fresh LZ File Measured Against What It Replaces

Questions About Building a New LZ Archive

Why would I choose .lz over the far more common .zip or .gz?
Mainly for lzip's documented 3-factor integrity check — a separate CRC32, data size, and member size verification built into every file — plus generally tighter LZMA-based compression than gzip's DEFLATE achieves on the same data.

Can I put more than one file into a single .lz archive?
Not directly. Lzip compresses one continuous stream at a time, so multiple files need to be bundled with tar first, producing the combined ".tar.lz" extension rather than a plain .lz file.

Will everyone I send an .lz file to be able to open it?
Not without some setup on Windows or macOS specifically. Stock 7-Zip and WinRAR don't include native lzip support; the recipient generally needs the separate Lzip7z plugin, a tool like Bandizip, or lzip itself installed.

Is building an .lz file slower than building a .zip or .gz?
Yes, generally. Lzip's LZMA-based compression takes noticeably longer than gzip's DEFLATE at comparable settings, according to lzip's own published benchmark data, though it often produces a smaller result in exchange.

What happens if my newly built .lz file gets corrupted later?
Lzip ships with lziprecover, a dedicated tool built specifically to use the format's own CRC32, data-size, and member-size trailer to recover as much of the original data as possible.

Does the .lz extension mean the same thing as .lzma?
No. A raw .lzma file is typically just the bare LZMA-compressed stream with a minimal or absent header, while .lz refers specifically to lzip's own container, complete with its magic bytes, version byte, dictionary-size byte, and three-factor integrity trailer.