LHA File Converter (What .LHA and .LZH Archives Actually Are)

Where the LHA Archive Format Actually Came From

The .lzh format traces back to a 1988 MS-DOS tool called LArc, written by Kazuhiko Miki, which compressed files using the LZSS algorithm developed by Haruhiko Okumura and used the .lzs extension. Haruyasu Yoshizaki — a medical doctor by profession, not a professional software developer — reused that same container structure for his own tool, LHarc, but swapped in a new compression method called LZHUF, itself a modification of an earlier Okumura design named LZARI. LZARI used arithmetic coding to squeeze data down; LZHUF replaced that with Huffman coding instead, which is where the "H" in LZH and LHA comes from.

That distinction matters because LZARI and LZHUF solve the same problem — squeezing repeated patterns out of a file — with two different final encoding steps. Arithmetic coding, used in LZARI, can theoretically pack data slightly tighter, but Huffman coding, used in LZHUF and every LHA method after it, is simpler and faster to decode on the modest hardware of the late 1980s, which is a large part of why Yoshizaki chose it for a tool meant to run on ordinary home computers.

The tool itself changed names several times as it matured: LHarc first, then briefly just "LH" in versions 2.02 through 2.04, then "LHa" for versions 2.05 and 2.06, before settling on "LHA" from version 2.10 onward. Development effectively stopped once Yoshizaki became busy with his day job, and the format has not seen active updates in decades — but it spread widely across Japanese bulletin board systems in the late 1980s and 1990s, and it remained a standard, still-used archive format on Amiga computers well after most of the world moved to ZIP.

How LHA's Compression Methods Actually Differ From One Another

Every entry inside an LHA archive is tagged with one of several compression "methods," and the differences between them are specific and documented, not arbitrary version numbers. Method -lh0- means the file is stored with no compression at all. Method -lh1- uses a 4 KiB sliding window with a maximum match length of 60 bytes and dynamic Huffman coding. Method -lh2- expands the window to 8 KiB with a 256-byte maximum match, still using dynamic Huffman. From -lh4- through -lh7-, the window size grows again — 4, 8, 32, and 64 KiB respectively — while switching to static (precomputed) Huffman tables instead of dynamic ones. The -lh5- method, with its 8 KiB window, became the de facto default for most LHA archives created through the 1990s, which is the version many old archives still floating around actually use.

LHA archives also carry a "header level" — 0, 1, 2, or 3 — that determines how file metadata like timestamps gets stored. Level 0 and level 1 headers pack the year into a compressed 7-bit DOS-style field, which was never designed to represent years past 2011; files timestamped after that point get silently reinterpreted as 1980 by strict readers of the old header format. Level 2 and 3 headers switched to a full 32-bit Unix timestamp instead, which solved the 2011 problem but inherits the same year-2038 rollover that affects other 32-bit time formats.

What You Gain and Lose by Converting an Old LHA Archive

• Gain — software that still gets security updates: the LHA/LZH format has had no active development for years, while ZIP, 7z, and the other current targets are maintained by tools that still patch newly found bugs.
• Gain — native support almost everywhere: Windows, macOS, and Linux all handle ZIP and TAR-based formats without hunting for a specific old utility, unlike LHA.
• Gain — freedom from the Shift-JIS filename problem: LHA archives built on Japanese systems often store filenames in Shift-JIS encoding; opening them on a system expecting a different encoding scrambles the names into garbled text, a problem that disappears once the files are repackaged with modern UTF-8-based filename handling.
• Lose — nothing about the actual file contents: extracting an LHA archive and repacking the same files into a current format changes only the container, not the data inside each file.
• Gain — protection from known LHA parsing bugs: security researchers documented stack-based buffer overflow and directory-traversal vulnerabilities (CVE-2004-0234 and CVE-2004-0235) in widely used LHA extraction code, meaning old, unpatched LHA tools can be a real risk when opening an untrusted archive.
• Lose — pointless compatibility with Amiga-era software: if the files never need to touch an Amiga or a legacy Japanese BBS-era program again, there's no reason to keep them in a format built for that ecosystem.

Which Current Programs Can Actually Open an .LZH File

Windows has never included native LHA/LZH support in File Explorer, at any version, including the current one. The standard build of 7-Zip does not support LHA/LZH either — this has been a long-standing, repeatedly requested feature on 7-Zip's own support forum, and the maintainers' position has been that a separate compression plugin would be needed to add it, not that it ships built in. WinRAR does list LZH among the "other" archive formats it can open and extract, alongside JAR, TAR, GZ, and several others, though — like those other formats — it can only unpack LZH, not create a new one, since WinRAR only writes RAR and ZIP.

PeaZip is one of the few current mainstream archivers that lists LHA/LZH directly among its natively supported formats for opening and extracting. Older Japanese versions of Windows shipped with Microsoft-provided LZH extraction support built directly into the OS, which is part of why the format persisted so long in that market specifically, even as the rest of the world standardized on ZIP. None of these tools can create genuinely new LHA archives with modern software — the format is effectively read-only territory today, encountered rather than produced.

The Specific Problems People Actually Run Into With LHA Files

The most common complaint is simply "nothing on my computer will open this file," which traces directly back to the fact that no major operating system ships with built-in LHA support and the most popular free archiver, 7-Zip, doesn't include it either — the practical fix documented across forums is installing PeaZip or another archiver that specifically lists LZH support, rather than assuming the file is corrupted.

A second recurring issue is scrambled, unreadable filenames after extraction — this happens when an archive built on a Japanese system using Shift-JIS encoding gets opened by a tool that assumes a different character encoding for filenames, producing a folder full of garbled names even though the file contents themselves extracted correctly. Some modern extraction tools address this by trying several encodings (Shift-JIS, EUC-JP, UTF-8) automatically or letting the user pick one manually.

A third, more serious historical issue involves security patches: the CVE-2004-0234 and CVE-2004-0235 vulnerabilities affected the Unix lha extraction tool up through version 1.14, allowing a maliciously crafted archive to trigger a buffer overflow or write files outside the intended extraction folder when opened or tested. Distributions like Red Hat and Gentoo issued advisories and patches at the time, and the underlying lesson — treat old, unmaintained LHA tools opening unfamiliar archives with real caution — still applies to any copy of that old software still in use today.

LHA/LZH Facts Worth Knowing at a Glance

Common Questions About Opening and Converting LHA Files

What's the difference between .lha and .lzh?
None in practice — they're the same archive format under two different extensions, both stemming from Haruyasu Yoshizaki's original LHarc tool and its LZSS-plus-Huffman compression method.

Why won't Windows open my .lha file?
Because Windows has never included LHA support built into File Explorer, at any version. A separate archiver that specifically lists LZH support, such as PeaZip, needs to be installed first.

Does 7-Zip support LHA files?
Not in the standard release. It's been a repeated request on 7-Zip's own discussion forum for years, with the response being that a separate plugin would be required, since it isn't built in.

Why are the filenames inside my LHA archive garbled?
The archive was likely built on a Japanese system using Shift-JIS character encoding for filenames, and whatever extracted it assumed a different encoding. Trying a tool that supports multiple filename encodings usually resolves it.

Is it safe to open an old LHA file with old software?
Use caution with unmaintained extraction tools specifically. Documented vulnerabilities (CVE-2004-0234 and CVE-2004-0235) let a maliciously crafted LHA archive trigger a buffer overflow or write files outside the intended folder in older lha software.

Can I create a new LHA archive today?
Realistically, there's little modern software left that writes genuinely new LHA/LZH files; the format today is almost entirely something people need to open, not create.