Convert LHA to ZIP Online (A Frozen 1988 Format Meeting the World's Default Archive)

What Actually Sits Inside an LHA File Before It Becomes a ZIP

LHA — carrying either the .lha or .lzh extension — dates to 1988, when Haruyasu Yoshizaki, a medical doctor rather than a professional developer, built the original LHarc tool on top of an existing container format from a 1988 MS-DOS program called LArc. Yoshizaki's own contribution was a new compression method named LZHUF, which combined LZSS-style dictionary matching with Huffman coding, replacing an earlier Okumura design called LZARI that had used arithmetic coding instead. Every file inside an LHA archive carries a method tag, from -lh0- (no compression) through -lh7- (a 64 KiB window with static Huffman tables), with -lh5- and its 8 KiB window becoming the format's de facto standard through the 1990s.

ZIP comes from an unrelated lineage entirely. Defined by PKWARE's APPNOTE.TXT specification, first published in 1989 and still revised today, ZIP gives every file its own local header, its own compressed data, and its own CRC-32 checksum, tied together by a central directory at the very end of the archive that lists every entry's name, size, and byte offset. Converting an LHA archive to ZIP means decompressing each entry out of its LZHUF encoding and rebuilding it as an independent ZIP entry with DEFLATE compression (or storing it uncompressed), plus a fresh central directory covering the whole set.

Per-Entry Method Tags Versus a Central Directory Built for Random Access

LHA already compresses each file as an individually tagged entry, which sounds similar to ZIP's own per-entry structure — but the two solve different problems. LHA's method tags exist to describe compression choices; there's no separate index recording where each entry starts within the archive beyond reading through it sequentially. ZIP's central directory, by contrast, is built specifically so a program can jump straight to any one file's data without reading every entry that comes before it, which is why ZIP tools can list an archive's contents or extract a single file almost instantly even from a very large archive.

LHA's header levels — 0 through 3 — control how file metadata gets stored, and this is where a real, documented limitation shows up. Levels 0 and 1 compress each file's timestamp into a 7-bit DOS-style year field that was never designed to represent years past 2011; archives using those older header levels get their post-2011 timestamps silently reinterpreted as 1980 by strict readers. Levels 2 and 3 switched to a full 32-bit Unix timestamp, solving that specific problem while inheriting the same 2038 rollover that affects other 32-bit time fields. ZIP's own timestamp field, defined by the original 1989 DOS date-time format in APPNOTE.TXT, caps years at 2107 — a limit far enough out that it isn't a practical concern for files being converted today.

What Rebuilding an Old LZH Archive as a ZIP Actually Changes

• Gain — near-universal native support: Windows Explorer has opened ZIP files natively since Windows XP, and macOS Finder and virtually every Android and iOS file manager handle it directly too, unlike LHA, which needs a specific separate tool everywhere.
• Gain — instant access to any single entry: ZIP's central directory lets one file be extracted or previewed without decompressing anything else first, a structural advantage LHA's sequential entry layout doesn't offer the same way.
• Gain — optional real encryption: ZIP supports AES-256 password protection through the WinZip/7-Zip extension, while LHA's format has no built-in encryption scheme at all.
• Lose — LHA's per-file method flexibility: each LHA entry could carry a different method tag chosen for that specific file's content; ZIP entries typically standardize on DEFLATE or stored, without LHA's range of window sizes.
• Gain — freedom from LHA's Shift-JIS filename problem: archives built on Japanese-locale systems often store names in Shift-JIS encoding, which garbles on a system expecting a different default; rebuilding as ZIP with standard UTF-8 handling ends that recurring issue for good.
• Gain — protection from documented LHA parsing bugs: CVE-2004-0234 and CVE-2004-0235 describe a buffer overflow and directory-traversal vulnerability in the Unix lha tool through version 1.14, a risk that simply doesn't apply once the data lives in a current ZIP file handled by modern software.

Which Systems Open Each Format Without Extra Software

ZIP has no meaningful compatibility gap left anywhere. It's been built into Windows Explorer since Windows XP, into macOS's Finder and Archive Utility since early versions of Mac OS X, and into essentially every mobile file manager on Android and iOS — nobody receiving a .zip file needs to install anything extra to open it.

LHA sits at the opposite end of that spectrum. Windows has never included native LHA/LZH support in File Explorer, at any version, and the standard build of 7-Zip doesn't include it either, despite it being a long-standing, repeatedly requested feature on 7-Zip's own support forum — the maintainers' position has been that a separate plugin would be needed. WinRAR lists LZH among the "other" archive formats it can open, alongside JAR, TAR, and several others, but like those, it can only extract LZH, never create it, since WinRAR itself 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.

Documented Problems People Actually Hit With This Conversion

The most common complaint by far is that nothing on a current computer will open the .lzh file to begin with — this traces directly to the fact that neither Windows nor stock 7-Zip supports LHA natively, and the fix documented across forums is installing PeaZip or another archiver that specifically lists LZH support, rather than assuming the file itself is corrupted.

A second recurring problem is scrambled filenames surviving the conversion: an LHA archive built on a Japanese system using Shift-JIS encoding, extracted by a tool assuming a different default character set, produces garbled names that get faithfully carried into the new ZIP if the encoding mismatch isn't caught first. Fixing filename encoding at the extraction stage — before rebuilding the ZIP — is the documented way to stop the problem from following the files forward.

A third, more serious historical issue concerns the extraction software itself: CVE-2004-0234 and CVE-2004-0235 describe a stack-based buffer overflow and a directory-traversal bug in the Unix lha tool through version 1.14, letting a maliciously crafted LHA archive write files outside its intended folder when opened. Red Hat and Gentoo issued advisories and patches at the time, and the underlying advice still applies today — extract old, unfamiliar .lzh archives with current, actively patched software rather than a decades-old copy of the original tool, before converting anything forward.

LHA/LZH and ZIP Placed Side by Side

Questions About Turning an Old LZH Archive Into a ZIP

Why won't my .lzh file open on a current Windows computer?
Because Windows has never included native LHA/LZH support in File Explorer, at any version, and the standard release of 7-Zip doesn't include it either. A tool like PeaZip, which lists LZH support directly, needs to be installed first.

Will the ZIP end up bigger or smaller than the original LHA file?
It depends on the content, but ZIP's standard DEFLATE method generally lands close to LHA's -lh5- results on typical files; LHA's later methods with larger windows, like -lh6- or -lh7-, sometimes edge it out on specific data.

Why are the filenames inside my archive scrambled after extraction?
The archive was likely built on a Japanese system using Shift-JIS character encoding for filenames, and whatever extracted it assumed a different default encoding. Fixing this before rebuilding as ZIP prevents the same garbling from showing up again.

Can I password-protect the ZIP after converting?
Yes. ZIP supports both the older ZipCrypto scheme and the stronger AES-256 extension used by 7-Zip and WinRAR, neither of which exists anywhere in the original LHA format.

Is it risky to open an old LHA file with old software before converting?
With unmaintained extraction tools specifically, yes. 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.

What's the actual difference between .lha and .lzh in this conversion?
None functionally — both extensions refer to the same underlying format built on Yoshizaki's LZSS-plus-Huffman method, so converting either one to ZIP follows exactly the same process.