Boundaries

Performances / limitations

JSZipp optimizes for safe browser ZIP handling and compact dependency-free integration, not for every raw compression benchmark.

Memory model

Each input entry is read and prepared before its ZIP records are emitted. Output streaming can avoid collecting the final archive in one object, but large individual entries still drive peak memory.

Compression

Writer compression is implemented in-repo and supports store plus deflate. Already-compressed files may be best stored or compressed at a low level.

ZIP64

ZIP64 is supported, but JavaScript number limits still apply. Values beyond Number.MAX_SAFE_INTEGER are rejected.

Browser APIs

Reading deflated entries depends on DecompressionStream. Runtime support should be verified for your browser baseline.

Practical limits

Set maxArchiveSize and maxEntrySize for untrusted inputs.
Prefer outputAs: "stream" for large final archives when the destination can consume a stream.
Avoid materializing every entry at once when copying or inspecting large archives.
Use pathMode: "strict-package" for package-like uploads where duplicate or colliding names are meaningful attacks.

Benchmarking

Use demo/library-benchmark.html as the local comparison harness, then validate with the exact archive shapes and browser targets your app uses.

Important limitation: JSZipp's stream-shaped writer does not mean true per-payload streaming compression.