Convert LZ to TAR Online (Removing lzip's LZMA Compression Entirely)

A Format Built for Integrity Meeting One Built for Tape Drives

Lzip is a compression format created by Antonio Diaz Diaz and first released in 2008, documented in a published IETF Internet-Draft that also registers "application/lzip" as a formal media type. Every .lz file it produces carries real, specific engineering: LZMA-compressed data wrapped in a container that opens with the four-byte signature "LZIP" and closes with a trailer holding a CRC32, the original data size, and the compressed member size — what lzip's own documentation calls a "3-factor integrity check."

Plain TAR comes from a completely different tradition and era. Designed in the early Unix world specifically to write sequences of files onto magnetic tape drives, TAR applies no compression and no checksum of any kind to the data it stores — each file simply gets a 512-byte header recording its name, size, and permissions, followed by the file's raw bytes padded out to the next 512-byte boundary, as fixed by the 1988 POSIX ustar standard. Converting an .lz file to plain TAR means decompressing the LZMA stream back to the original data, discarding lzip's integrity trailer entirely, and writing that raw data into TAR's much simpler, uncompressed layout.

Why This Conversion Removes Engineering Rather Than Adding It

Almost every other archive format covered in a typical conversion tool — 7z, ZIP, RAR, tar.gz, tar.bz2 — keeps some form of compression and some form of integrity checking active on the far end of a conversion. Plain TAR is the outlier: it was never designed to do either job, leaving both entirely to whatever tool or process runs before or after it. That makes LZ-to-TAR a conversion that strips away lzip's specific, documented 3-factor integrity check and its LZMA compression at the same time, rather than trading one compression method or one checksum scheme for a different one.

Lzip's own single-stream design already limits it to holding one file's data (or one tar stream) per .lz archive, which means a .tar.lz file specifically is already a tar archive that's been compressed with lzip afterward. Converting a .tar.lz file to plain .tar is, in that specific case, closer to just removing lzip's compression layer and getting back the original tar stream that was there all along, rather than restructuring the archive's internal layout the way converting to ZIP or 7z would require.

A plain .lz file that never held a tar stream to begin with — just one compressed file directly — needs an actual tar step added during this conversion, since TAR's format has no concept of "a single loose file" the way a raw compressed stream does; it always wraps content in its own header-plus-data block structure, even for one file.

Knowing which of those two cases applies matters before running the conversion. A .tar.lz archive downloaded from a project like the IANA Time Zone Database or the Linux-libre kernel, both of which distribute some releases this way, already contains a full tar stream with per-file headers, permissions, and ownership data intact underneath lzip's compression — decompressing it hands back that same structure directly. A plain .lz file compressing one arbitrary file, by contrast, has no such metadata baked in beyond whatever lzip itself records, so building a genuinely useful TAR archive from it means deciding what name, permissions, and timestamp the new tar header should carry for that single file.

What Actually Changes Going From LZ to Plain TAR

• Lose — all compression: the resulting .tar file will almost always be larger than the original .lz file, since plain TAR stores data raw with no compression pass at all.
• Lose — lzip's three-factor integrity check: the CRC32, data-size, and member-size verification in lzip's trailer has no replacement in plain TAR's format, which carries no checksum of its own.
• Gain — a format with essentially zero encoding complexity to fail: TAR's fixed 512-byte header blocks are simple enough that virtually every Unix-like system reads and writes them without any special library.
• Gain — a natural fit for a fresh compression pass afterward: a plain TAR file can be piped straight into gzip or bzip2, which is exactly the two-step process behind .tar.gz and .tar.bz2.
• Lose — access to lzip's own recovery tooling: lziprecover is built specifically around lzip's trailer format to recover data from a damaged .lz file; plain TAR has no bundled recovery utility of its own.
• Gain — direct Unix ownership and permission metadata: TAR's headers record file mode, owner, and group for every entry, which a single compressed .lz stream, holding just one file's raw data, doesn't carry on its own.

Where Plain TAR Opens for Free and LZ Still Needs Extra Software

The tar command is a standard, pre-installed utility on essentially every Linux distribution and on macOS, since both trace directly back to the Unix lineage that produced the format. Windows 10, starting with its 2018 update, added a native command-line tar.exe built on the libarchive project, letting a plain .tar file be extracted straight from Command Prompt or PowerShell with nothing extra installed.

Lzip has no equivalent free path on Windows or macOS. 7-Zip's standard build does not include native lzip support at all — opening or creating .lz files with it requires the separate Lzip7z plugin — and WinRAR's own documented format list, covering RAR, ZIP, and extraction support for 7z, ISO, JAR, BZ2, GZ, TAR, and ARJ among others, doesn't include lzip anywhere on it. GNU tar itself has handled lzip transparently since version 1.23 through its own --lzip option, which is arguably the most convenient existing path for decompressing an .lz file before this conversion even runs.

Real Complaints Behind Converting LZ Files to Plain TAR

The most common surprise is the resulting .tar file being noticeably larger than the original .lz archive — this isn't a mistake, it's the direct, expected result of plain TAR applying no compression at all while lzip's LZMA-based method actively shrank the data beforehand. People expecting a like-for-like archive swap are often unprepared for exactly how much bigger a plain, uncompressed tar file turns out to be, especially for text-heavy or source-code-heavy content that compresses well under LZMA.

A second real pattern shows up on 7-Zip's own SourceForge discussion forums: people downloading a .tar.lz release and finding stock 7-Zip doesn't recognize the extension, since lzip isn't built into the standard release — the practical route from there is either installing the separate Lzip7z plugin or using GNU tar's own --lzip support to get at the contents first.

A third issue involves losing lzip's specific integrity guarantees without realizing it: someone converting a .lz file specifically because they wanted a simpler, more universally readable container can be caught off guard learning that plain TAR carries no checksum mechanism of its own at all, meaning any corruption that creeps in afterward won't be caught the way lzip's 3-factor trailer would have caught it in the original file.

LZ and Plain TAR Compared

Questions About Turning an LZ Archive Into Plain TAR

Why is my converted TAR file bigger than the original LZ file?
Because plain TAR applies no compression at all, while lzip's LZMA-based method already shrank the data. Converting from a compressed format to an uncompressed one always increases size, and this is expected, not an error.

Should I compress the TAR file again afterward?
That's the standard next step if smaller size matters — piping the plain TAR file into gzip or bzip2 produces a tar.gz or tar.bz2 archive, giving back roughly the compression lzip already offered, just through a different algorithm.

Does plain TAR check my file for corruption the way LZ did?
No. TAR's format carries no checksum mechanism of its own, unlike lzip's 3-factor trailer, which independently verifies a CRC32, the original data size, and the compressed member size on every file it produces.

Can Windows open a .tar file without installing anything?
Yes, starting with Windows 10's 2018 update, which added a native tar command usable from Command Prompt or PowerShell, no separate program required.

Is there a reason to skip compression entirely and use plain TAR?
Yes, when the files are about to be compressed again with a different algorithm, or need inspection or reassembly first — starting from a plain, uncompressed TAR bundle avoids working through lzip's LZMA encoding twice.