ZIP Files Larger Than 4 GB in JavaScript (ZIP64)

The original ZIP format stores sizes in 32 bits and entry counts in 16 — hard ceilings of 4 GB (per file and per archive) and 65,535 entries. Cross either line with a classic writer and you get corrupt output or extraction errors. ZIP64, the format's 64-bit extension, removes both limits — and the practical questions are which tools write it, which tools read it, and whether a 4 GB browser archive is a good idea at all.

What Eazip.js writes

Local archives from Eazip.js use ZIP64, so large entry counts and offsets don't hit the legacy limits — there is no flag to set and no 32-bit cliff to avoid:

const result = await createZip({
  files, // more than 65,535 entries or > 4 GB — same call
  zipName: 'big-export.zip',
});

Managed Eazip jobs are ZIP64 as well, so the format question is settled on both paths.

Will your users be able to open it?

Modern environments, yes: the built-in extractors of current Windows, macOS, and mainstream Linux tools handle ZIP64, as do the major third-party tools (7-Zip, WinRAR, Keka, unzip 6+). Where it still bites:

• Ancient tooling — very old unzip builds and legacy Java-era libraries predate ZIP64 support.
• Half-modern pipelines — an automated consumer on the other end (an old ETL job, an embedded device) is likelier to choke than a person's desktop.

If your archive's consumers are unknown machines rather than humans, splitting below 4 GB per part sidesteps the question entirely:

const result = await createZip({
  files,
  zipName: 'export.zip',
  maxZipSizeBytes: 3_500_000_000, // parts stay under the legacy line
});

result.downloadAll();

(Multi-ZIP splitting covers part naming and assignment.)

The real problem at 4 GB usually isn't the format

A 4 GB archive built in a tab is deep into browser memory territory, and a 4 GB single download is fragile for whoever receives it. At this size the format is the solved problem; the runtime is not. The usual endgame is the managed path — same call with strategy: 'cloud' — where the archive builds off-tab and delivery is a resumable link (Scale with Eazip).

FAQ

Do I need to enable ZIP64 explicitly?

No. Local Eazip.js output uses ZIP64; there is no option to set.

Can Windows / macOS built-in extractors open ZIP64 archives?

Current versions, yes. Failures in practice come from very old tools and libraries, not from up-to-date desktop OSes.

Is there still a per-file limit?

Not from the format — ZIP64 fields are 64-bit. The practical limits are memory (browser) and plan output caps (managed: 50 GB per archive, auto-split beyond).

Should I just split instead?

If unknown or legacy consumers will open the output, parts under 4 GB are the safe, boring answer — and smaller parts download and resume more gracefully anyway.