What Is an .LZMA File? (The Standalone Format 7-Zip Used Before XZ Existed)

The Old Standalone Format That Existed Before XZ

A .lzma file holds data compressed with the LZMA algorithm using a simple, older container often called LZMA_Alone, referring to the original reference encoder that produced it. Igor Pavlov, LZMA's creator and the developer of 7-Zip, placed the LZMA SDK in the public domain on December 2, 2008, with the release of 7-Zip version 4.62. Before the .xz format existed, this standalone .lzma format was the closest thing to a portable, file-based way to use LZMA compression outside of 7-Zip's own .7z archive container, and command-line tools built specifically around it, including the original `lzma` utility, treated it as a complete file format in its own right rather than as part of a larger archive.

That distinction matters because LZMA compression itself was never exclusive to this standalone format. The .7z container, introduced by 7-Zip in 2001, has always used LZMA as one of its internal compression methods, storing it inside 7z's own richer structure with per-file metadata and its own checksums. The standalone .lzma format is a separate, much thinner wrapper: essentially just a header followed directly by raw compressed data, built for situations where a full archive container was more than what was needed.

Inside the 13-Byte Header That Defines This Format

Every .lzma file opens with exactly 13 bytes of header before the compressed data begins. The first byte encodes three compression parameters packed together — lc (literal context bits), lp (literal position bits), and pb (position bits) — using a single formula. The next four bytes record the dictionary size the encoder used. The final eight bytes store the uncompressed size of the original data. If that size wasn't known when compression started, the format uses the special value 0xFFFFFFFFFFFFFFFF (all bits set) to mean "unknown," which tells the decompressor to instead watch for an end-of-payload marker embedded in the compressed stream itself, rather than simply reading a fixed number of bytes.

That 13-byte header contains no magic number at all — no fixed byte sequence that reliably marks a file as being in this format the way ZIP's "PK" signature or gzip's 0x1F 0x8B bytes do. A file-type detector looking at raw .lzma data has to infer the format from context, such as the file extension or surrounding metadata, rather than reading a guaranteed signature from the bytes themselves, which is a real, documented limitation of the format as originally designed.

What This Older Format Never Included

• No built-in checksum: the .lzma format has no CRC or hash covering the compressed or decompressed data, so nothing in the file itself flags corruption.
• No magic number for identification: unlike ZIP, gzip, or xz, a raw .lzma file can't be reliably identified from its first bytes alone.
• No multi-stream concatenation: the format holds exactly one compressed stream per file, with no defined way to safely join several .lzma streams into one file the way xz supports.
• An ambiguous unknown-size case: when the uncompressed size is marked unknown, correctly detecting the end of the stream depends on the decoder handling the embedded end marker properly, a detail some early or minimal implementations got wrong.
• No filter chaining: the standalone format applies LZMA1 alone, with none of the multiple-filter pipelines xz's container supports for tasks like delta filtering before compression.

Which Tools Still Open a Legacy .LZMA File Today

XZ Utils, the toolset that also produces .xz files, keeps compatibility with the older format through its own `lzma` command-line alias and an explicit `--format=lzma` option, so anyone with a current xz-utils install can still decompress old .lzma files without hunting down separate legacy software. Python's standard `lzma` module documents a `FORMAT_ALONE` constant specifically for reading and writing this older container, kept precisely because real .lzma files from before 2009 are still encountered in the wild.

7-Zip's own GUI and command-line tool continue to recognize .lzma as a distinct format separate from .7z, since Igor Pavlov's SDK originated both. That said, 7za.exe, the standalone lightweight edition of 7-Zip's command-line tool, documents a narrower format list than the full 7-Zip package, so which specific 7-Zip build is installed can determine whether a given .lzma file opens directly or needs the fuller GUI version instead.

Outside of xz-utils, 7-Zip, and language libraries like Python's, general support for the standalone .lzma format is genuinely narrow. WinRAR's own documented format list does not call out .lzma the way it calls out .7z, .zip, and several others by name, and mainstream mobile archive apps built around ZIP and RAR frequently skip this older, less common format entirely.

Linux distributions largely followed the same path as xz-utils: package managers that once accepted .lzma-compressed sources moved to .xz once it became available, keeping .lzma decoding around mainly as a fallback for older packages already published rather than as an actively used format for anything new. That pattern — full read support for backward compatibility, but nothing new being written in the old format — is the same shape the transition took across almost every tool that touched LZMA compression during the following years.

Why an Old .LZMA File Sometimes Fails to Open Cleanly

A documented, recurring issue on Stack Overflow and various tool-specific forums involves a decompressor misreading the 13-byte header because the uncompressed-size field was set to the unknown-size marker, and the specific tool trying to read it wasn't built to correctly watch for the end-of-payload marker instead — producing either a truncated result or an outright error, despite the file itself being perfectly intact. This is precisely the kind of ambiguity that later formats like xz addressed directly, by defining unambiguous stream boundaries rather than leaving end-of-stream detection to depend on how carefully a given decoder implements the unknown-size case.

A second real, documented problem is that because the format carries no magic number, some general-purpose file-identification tools and libraries genuinely cannot distinguish a valid .lzma file from arbitrary binary data without being told the extension explicitly, unlike gzip or ZIP files, which self-identify from their first bytes. Scripts and pipelines that rely on automatic content-type detection rather than trusting the file extension have documented issues specifically because of this gap.

A third pattern involves confusing the standalone .lzma format with LZMA compression used inside a .7z archive — the two share an algorithm but not a container, so a tool built only to read .7z files, expecting 7z's own headers and central directory structure, cannot open a raw standalone .lzma file at all, and the reverse is equally true.

A fourth, more procedural issue shows up in older build scripts and Makefiles written specifically around the standalone `lzma` command from years before xz-utils existed as a combined tool — those scripts sometimes hardcode calls that assume the legacy binary's exact command-line behavior, and simply swapping in a modern xz-utils install without checking its `--format=lzma` compatibility flag can produce a file that isn't quite what the downstream step in the script expects.

The Legacy Standalone Format Set Against What Replaced It

Common Questions About Opening an Old .LZMA File

Is a .lzma file the same thing as a .7z file?
No. Both can use the LZMA algorithm, but .7z is a full archive container with its own headers and per-file structure, while .lzma is a much thinner standalone format holding one compressed stream with a 13-byte header and nothing else.

Why doesn't my file-type detector recognize a .lzma file?
Because the format has no magic number — no fixed byte signature at the start of the file — so tools that rely on reading a known signature to identify a format often can't confirm a .lzma file without being told its extension directly.

Can I still open old .lzma files with modern software?
Yes. XZ Utils supports them through its `lzma` command or `--format=lzma` option, Python's `lzma` module has a dedicated `FORMAT_ALONE` constant for them, and 7-Zip still recognizes the format directly, even though .xz has replaced it for new files.

Why did this format get replaced by .xz in 2009?
Mainly because it lacked a magic number for reliable identification, had no built-in checksum to detect corruption, and handled unknown file sizes through an ambiguous end-of-stream marker that different decoders could interpret inconsistently — all problems the .xz container was built specifically to solve.

Does a .lzma file support compressing more than one file at once?
No. The format holds a single compressed stream. Bundling multiple files requires an archiving step, like tar, done separately before LZMA compression is applied to the combined result.