Convert LZ to TAR.GZ Online (From a Format Built for Archival Integrity to the Web's Default)

What an .LZ File Is Before It Becomes a TAR.GZ

An .lz file is the output of lzip, a compressor created by Antonio Diaz Diaz and first released in 2008. Lzip compresses data using LZMA, the same core algorithm 7-Zip and xz both rely on, but wraps it in a deliberately simple container documented in an IETF Internet-Draft that also registers "application/lzip" as a formal media type. Every lzip file starts with the four-byte magic sequence 0x4C 0x5A 0x49 0x50, spelling out "LZIP" in ASCII, followed by a version byte and a coded dictionary-size byte, then the compressed data itself, and finally a trailer holding the CRC32 of the original uncompressed data plus its exact size in bytes.

That trailer is the detail worth knowing before converting: lzip's own documentation describes this as "3-factor integrity checking," meaning a decompressor can independently verify the data size, the CRC32 of the decompressed output, and the member size, catching corruption that a simpler format might miss. TAR.GZ works differently. Tar bundles multiple files into one stream using 512-byte header blocks, and gzip then compresses that stream using DEFLATE, storing a single CRC-32 checksum for the entire compressed payload rather than lzip's three separate checks. Converting from LZ to TAR.GZ means decompressing the lzip stream, and, since lzip compresses only a single file or a single tar stream, then either recompressing that same content with gzip directly, or wrapping the extracted files in a fresh tar archive before gzip runs, depending on what the .lz file originally held.

Why Lzip's Own Project Argues Against Formats Like XZ

Lzip's documentation includes a page titled "Xz format inadequate for long-term archiving," which lays out specific, named criticisms of the xz container: none of the many length fields in the xz format are protected by a checksum, xz's variable-length integer encoding can suffer what the page calls a "double framing error" where corruption changes both a field's value and its byte length at once, and xz's integrity check is optional per-stream rather than mandatory. By contrast, the same documentation states lzip protects all of its length fields and requires no optional check types, positioning lzip as the more conservative choice specifically for data meant to remain readable decades later.

Gzip sits in a different spot on that spectrum. It predates both lzip and xz, using DEFLATE rather than LZMA, and its single whole-stream CRC-32 is simpler than lzip's three-factor check but has been stable and essentially unchanged since gzip's own file format was finalized in the early 1990s. Converting an .lz file to .tar.gz doesn't inherit lzip's extra verification layers; what it gains instead is a compression format that virtually every operating system, programming language, and archive tool already understands without installing anything extra.

What Switching From LZ to TAR.GZ Actually Changes

• Lose — lzip's three-factor integrity check: the separate CRC32, data-size, and member-size verification in lzip's trailer is replaced by gzip's single whole-stream CRC-32.
• Gain — near-universal software support: gzip decompression is built into essentially every mainstream OS and archive tool, while lzip often needs a dedicated package or 7-Zip plugin installed first.
• Lose some compression ratio in typical cases: lzip's LZMA-based compression generally produces smaller output than gzip's DEFLATE on the same data, since DEFLATE's 32 KiB window is far smaller than LZMA's configurable dictionary.
• Gain — much faster compression and decompression: gzip is markedly quicker than lzip at comparable settings, a real trade against the smaller file lzip would have produced.
• Gain — proper multi-file bundling if needed: lzip compresses one data stream at a time, so archiving several files as .lz requires tar first; TAR.GZ makes that same tar-then-compress structure the norm rather than an extra step.
• Lose — lzip's documented recovery tooling: lzip ships with lziprecover, built specifically to recover data from a damaged .lz file using its three-factor checks; gzip has no equivalent recovery utility bundled with it.

Where LZ Files Show Up and Where TAR.GZ Already Works

Lzip's own project page and Wikipedia both document real adopters: the IANA Time Zone Database ships .lz-compressed releases, the Linux-libre kernel project distributes some files this way, and GNU Automake includes a "dist-lzip" option for generating .lz-compressed source tarballs alongside the more common .tar.gz. GNU tar, from version 1.23 onward, can decompress lzip archives transparently through its own --lzip option, and GNOME's Archive Manager also opens the format directly on Linux desktops.

Windows and macOS tell a narrower story. 7-Zip does not include native lzip support out of the box; opening or creating .lz files with it requires the separate Lzip7z plugin, a small add-on distributed independently of the main 7-Zip project. WinRAR's own documented format list — RAR, ZIP, and extraction support for 7z, ISO, JAR, BZ2, GZ, TAR, ARJ, and several others — does not include lzip at all. TAR.GZ avoids all of this: gzip decompression ships in Windows' modern tar.exe, in macOS's Archive Utility, and in essentially every Linux package manager's base install, with no plugin required on any of the three.

Real Complaints Behind Requests to Convert an LZ File

A recurring, documented pattern on 7-Zip's own SourceForge discussion forums involves users downloading a .tar.lz or .lz release from a project like GNU software and finding that stock 7-Zip simply doesn't recognize the extension, prompting them to either hunt down the separate Lzip7z plugin or ask the release maintainer for a .tar.gz alternative instead. This isn't a corrupted download; it's a genuine format-support gap between what a project chose to publish and what the recipient's installed tools already handle.

A second real issue traces back to lzip's own compression speed: because lzip uses LZMA rather than DEFLATE, compressing large files takes noticeably longer than gzip does at comparable settings, according to lzip's own published benchmark page, which some users encounter as an unexpectedly long wait when building an .lz archive from a large dataset. Converting to TAR.GZ afterward doesn't undo that original compression time, but it does mean any future recompression of the same data runs faster.

A third pattern shows up in mixed-OS teams: a Linux-based build server produces .lz release artifacts because the toolchain defaults to lzip, and Windows-based teammates without the Lzip7z plugin installed can't open them at all, which is a documented, specific compatibility gap rather than a corrupted file — the fix in practice is either installing the plugin or having the build server also emit a TAR.GZ copy for wider reach.

A fourth pattern is version confusion rather than a missing tool: lzip's own release history documents changes to the coded dictionary-size byte and version field across releases, meaning a very old lzip build can occasionally reject a file written by a much newer one, or vice versa, until both sides update. TAR.GZ carries essentially no equivalent risk, since gzip's on-disk format hasn't meaningfully changed since it was standardized, so a decompressor from decades ago still reads a file compressed yesterday without any version negotiation at all.

LZ and TAR.GZ Set Side by Side

Questions About Turning an LZ Archive Into a TAR.GZ

Why would a project ship .lz instead of the far more common .tar.gz?
Mostly for the stronger integrity checking lzip's format documents — a separate CRC32, data size, and member size check — plus somewhat better compression than gzip achieves on the same data, at the cost of slower compression and narrower software support.

Can I open an .lz file on Windows without any extra software?
Not with stock 7-Zip or WinRAR. Neither includes native lzip support; opening the format on Windows generally requires the separate Lzip7z plugin or a tool like Bandizip that documents lzip support directly.

Does converting to TAR.GZ lose lzip's integrity checks?
Yes. Gzip replaces lzip's three-factor CRC32/size verification with a single whole-stream CRC-32, which is still useful for catching corruption but checks fewer things than lzip's original trailer does.

Will the converted TAR.GZ file be bigger than the original LZ file?
Often somewhat, yes. Lzip's LZMA-based compression tends to produce smaller output than gzip's DEFLATE on the same data, which is one of the documented reasons some projects choose lzip in the first place.

Is .tar.lz the same thing as a plain .lz file?
Not quite. A plain .lz file is lzip-compressed data from a single source stream; .tar.lz is a tar archive of multiple files that has then been compressed with lzip, the same two-step pattern .tar.gz uses with gzip.