Formats and limits
This page is the complete answer to “can it do X”. Everything below was established by running the shipped code against real archives, not by reading a library’s feature list.
What can be read and written
| Format | Read | Write | Password | Engine |
|---|---|---|---|---|
| ZIP | Yes — Store and Deflate, Zip64, CP437 and UTF-8 names, Info-ZIP Unicode Path records | Yes | Yes — ZipCrypto and WinZip AES-128/192/256 | Built-in JavaScript parser; encrypted or exotic-method archives are routed to WebAssembly |
| RAR 4 | Yes | No — RAR creation is proprietary and cannot be implemented | No — this build has no RAR crypto | libarchive (WebAssembly) |
| RAR 5 | Yes, including solid archives | No | No | libarchive (WebAssembly) |
| 7z | Yes — LZMA, LZMA2, BZip2, Deflate, Store | No — not implemented | No — this build has no 7z crypto | libarchive (WebAssembly) |
| TAR | Yes — v7, USTAR, PAX and GNU long-name extensions | Yes — USTAR with PAX headers for long paths | Not applicable — TAR has no encryption | Built-in JavaScript parser |
| TAR.GZ / .tgz | Yes | No — produce a .tar here and compress it locally | Not applicable | Browser DecompressionStream, then the built-in TAR parser |
| gzip (single file) | Yes — treated as one compressed file, named from the gzip header | No | Not applicable | Browser DecompressionStream |
| bzip2, xz, Zstandard (standalone) | No — recognised and reported by name, not read | No | Not applicable | — |
Why passwords work for ZIP and not for RAR or 7z
The WebAssembly engine is libarchive.js 2.0.2, which bundles libarchive 3.7.2, compiled without an external crypto backend. ZIP decryption is implemented inside libarchive itself and works. RAR and 7z decryption call out to that missing backend, so they do not.
The engine says so in its own words. Given a correct password, an encrypted 7z returns The file content is encrypted, but currently not supported, and a header-encrypted RAR returns RAR encryption support unavailable. Those exact strings are what the error messages here are built from.
The consequence for the interface: there is a password field on ZIP archives and there is not one on RAR or 7z. A field that accepts a password and then fails would be worse than no field at all.
Split and multi-volume archives
Not supported. A .part1.rar will happily list its first few entries and then stop, which looks like success and is not — so the volume flag is read out of the archive header and the file is refused with an explanation before anything is attempted. Spanned ZIP sets carry a spanning marker and are caught the same way. A .7z.001 is the exception: the 7z format records nothing in the first volume that says it is one, so there is no flag to read. It is reported as unreadable, with the message naming a split set as the likely cause, rather than being identified as a volume.
Joining them would need every volume resident in the tab at once, which is exactly the memory profile these limits exist to avoid.
Memory budgets
Browsers do not tell a page how much memory it may use, so these numbers are chosen to be safely below where tabs actually die. They are checked against the archive’s declared sizes before anything is decompressed.
| Limit | Desktop | Safari, phones, low memory |
|---|---|---|
| Archive file size | 2.0 GB | 384 MB |
| Total expanded size | 2.0 GB | 512 MB |
| Largest single file | 1.0 GB | 256 MB |
| Entry count | 100,000 | 25,000 |
| Expansion ratio | 250× | 250× |
| Directory depth | 64 | 64 |
The conservative column applies whenever the device cannot be shown to have headroom: any phone, any Safari, and any browser reporting 4 GB or less. Firefox does not implement navigator.deviceMemory at all, so it gets the conservative budget too — an unnecessarily cautious limit costs throughput, while an over-optimistic one costs the visitor their work.
What is deliberately not offered
- Creating RAR.Impossible. The compression format is proprietary and only RARLAB’s own tool can write one.
- Creating 7z or encrypted ZIP. Both are implementable and neither is implemented. A route is not offered for an operation that does not work.
- “ZIP to PDF” and similar.Turning an archive’s contents into a document is document generation, not an archive operation. A PDF that merely lists filenames would not preserve or meaningfully present the archived files.
- Previewing files inside archives. Listing and extracting only.
How format detection works
By the file’s own bytes, always. A ZIP renamed to .rar is read as a ZIP and flagged as mis-named; a 7z called .tar is read as a 7z. TAR is the awkward case — it has no signature at offset zero — so it is identified from the USTAR magic at byte 257 or, for the ancient v7 format, from a valid header checksum plus a plausible name field.