Convert Any File to LZMA Online (Building the Older Standalone Format on Purpose)

Writing the Older LZMA_Alone Container From Scratch

Building a new .lzma file means writing data in the standalone container format sometimes called LZMA_Alone, distinct from LZMA compression used inside a .7z archive even though both share the same underlying algorithm. Igor Pavlov, who created LZMA and built 7-Zip, placed the LZMA SDK in the public domain on December 2, 2008, and the standalone format that SDK's reference tools produced predates the .xz container, which the Tukaani Project released in 2009 specifically to replace it for general use. Choosing to write a new file in this older format today is a narrower decision than it would have been in, say, 2007, since .xz has been the default choice for new LZMA-compressed files for well over a decade.

The container itself is genuinely simple: a 13-byte header made of one byte encoding the lc/lp/pb compression parameters, four bytes for the dictionary size, and eight bytes for the uncompressed data size, immediately followed by the compressed data with nothing else wrapped around it. There's no magic number marking the start of the file, no checksum covering the result, and no support for concatenating multiple compressed streams into one file — all deliberate simplifications in the original design that later became documented reasons the format was retired in favor of something more robust.

Why Someone Still Targets This Specific Older Format

The most common documented reason to build a new .lzma file rather than a .xz file is compatibility with a specific existing tool or pipeline that was written against the older format and expects exactly that 13-byte header, not xz's more elaborate stream-and-block structure. Python's `lzma` module documents a `FORMAT_ALONE` constant precisely for this purpose — code that needs to produce output another system can already parse, where that other system predates or otherwise only understands the legacy format, has a real, non-hypothetical reason to keep writing it.

A second documented reason is minimizing overhead on the smallest possible files: xz's container adds stream header and footer bytes, block headers, and an integrity-check field, all of which are essentially fixed costs regardless of how little data is being compressed. On a very small file, that fixed overhead can matter proportionally more than it would on a large one, and the older format's thinner 13-byte header carries less of that fixed cost — though this savings is measured in bytes, not a difference that matters for anything beyond the smallest inputs.

A third, more specific reason shows up in firmware and bootloader contexts written years ago against a fixed decompression routine that only understands the legacy 13-byte header, not xz's more elaborate framing. Rewriting that routine to accept a newer container is often a bigger undertaking than simply continuing to produce the older format the routine already expects, particularly when the device or firmware in question isn't otherwise being actively modified.

What Choosing This Format Over XZ Gains and Costs

• Gain — a thinner, simpler header: 13 bytes total versus xz's multi-part stream, block, and footer structure, which matters mainly on very small files.
• Lose — any built-in corruption detection: the format has no checksum at all, unlike xz's optional CRC32, CRC64, or SHA-256 checks.
• Lose — reliable format identification: without a magic number, a raw .lzma file can't be confirmed from its own bytes the way a .xz file's fixed signature allows.
• Gain — compatibility with legacy tools built specifically around this container: some existing pipelines or scripts expect exactly this format and would need modification to accept .xz instead.
• Lose — filter chaining and multithreaded compression: xz's block structure enables splitting work across CPU cores and applying multiple filters in sequence; the older format supports neither.

Which Tools Can Actually Produce This Format Today

XZ Utils, despite being built around the newer .xz container, documents an explicit `--format=lzma` option specifically for producing files in the older standalone format, alongside its `lzma` command alias that defaults to legacy behavior for compatibility with scripts written before xz existed. 7-Zip's own command-line and GUI tools can also target this format directly, since Igor Pavlov's SDK is the common ancestor of both the legacy format and 7-Zip's later .7z container.

Python's `lzma` standard library module exposes `FORMAT_ALONE` as one of its documented format constants when opening a compressor, meaning any Python-based tool can generate a legacy .lzma file without depending on an external binary at all. Outside these specific paths, general-purpose archive tools built primarily around ZIP and RAR, along with most mobile file-manager apps, typically have no dedicated support for creating this older format, since real demand for producing new files in it has been narrow for well over a decade.

Real Problems That Come Up When Building This Format

A documented, recurring issue involves scripts that generate a .lzma file with the uncompressed size deliberately left unknown, relying on the 0xFFFFFFFFFFFFFFFF marker and an embedded end-of-payload signal, only to have some downstream tool misread that ambiguous case and either truncate the output or throw an error. The documented fix is specifying the known size explicitly wherever possible, rather than relying on every decoder correctly handling the unknown-size path the same way.

A second real complaint traces back to the missing checksum: teams that built automated pipelines around this legacy format sometimes only discover after the fact that there's no way to confirm a transferred or stored .lzma file arrived intact, since the format itself has nothing analogous to gzip's or xz's built-in verification. The practical workaround documented in various build systems is wrapping the file in an outer checksum manifest maintained separately, since the compression format itself won't provide one.

A third pattern involves the missing magic number specifically breaking automated content-type detection in web servers and file-upload systems that try to sniff a file's format from its bytes; without a fixed signature to check against, some of these systems fall back to treating the upload as generic binary data, which can affect how it's served, cached, or scanned downstream.

A fourth issue, documented in various packaging and build-tool discussions, involves developers assuming the legacy `lzma` command and the newer `xz` command are fully interchangeable simply because both ultimately call into the same underlying LZMA compression code. They aren't: pointing a build step at the wrong one produces a file in the wrong container entirely, and a downstream step expecting one specific format's header will fail against the other even though the actual compressed data underneath is conceptually similar.

Building the Legacy Format Compared With Building a Modern XZ File

Common Questions About Creating a Legacy .LZMA File

Should I create a new file as .lzma or .xz?
Almost always .xz, unless a specific existing tool or script needs exactly the older format. The .xz container has checksums, a magic number for reliable identification, and multithreaded compression support that the legacy format never had.

Can xz-utils still produce files in the old format?
Yes. Its `--format=lzma` option and `lzma` command alias both target the legacy standalone container directly, kept specifically for compatibility with scripts and tools written before .xz existed.

Is there any downside to building a .7z archive instead of a raw .lzma file?
A .7z archive adds real structure — its own headers, per-file metadata, and checksums — which a raw .lzma file doesn't have at all. That structure is generally an advantage, unless the goal specifically is the thinnest possible wrapper around a single compressed stream, since every added header and checksum field is also a few more bytes of overhead on a very small file.

Does this older format support compressing multiple files at once?
No. It holds a single compressed stream only. Bundling several files first requires a separate archiving step, such as tar, before this compression format gets applied to the result.

Will a newly created .lzma file be readable in ten or twenty years?
Likely yes technically, since xz-utils and Python's lzma module both document ongoing support for reading the format, but without a built-in checksum there's no way to confirm the file wasn't silently corrupted somewhere along the way.

Does 7-Zip default to the legacy format or the newer one when compressing?
Neither directly by default for most everyday use, since 7-Zip's default archive type is .7z using LZMA2 internally. Producing a raw standalone .lzma file requires explicitly selecting that output type rather than 7-Zip's usual archive format.