Open large RAR files online — 4 GB and beyond, no upload

What actually breaks at 4 GB

The problem is not disk space or download speed — it is three ceilings that sit inside every browser, and they bite long before the operating system would:

The first is the ArrayBuffer limit. A web page reads file data into memory as a single ArrayBuffer, and browsers cap how large one allocation can be. We measured this on the same engine the viewer runs on: Chrome accepted a 1.5 GiB allocation and refused 2 GiB outright — RangeError, before a single byte of your archive is even parsed. Safari and Firefox sit in the same territory. Any tool that reads your whole archive into one buffer — which is how most in-browser extractors are built — inherits this wall at roughly the size of a large photo session.

The second is WebAssembly addressing. RAR decompression runs on unrar compiled to WebAssembly, and a 32-bit wasm module can address at most 4 GiB of memory *total* — for the code, the decompressor state, and the archive data combined. An engine that loads the whole archive into wasm memory cannot physically accept a file larger than that, and in practice dies a gigabyte or two earlier.

The third is arithmetic: the old approach needs the archive in memory *at least* once (often twice — once to fingerprint, once to extract). A 4.5 GB archive on a path like that means 4.5–9 GB of RAM inside a browser tab. The tab gets killed, or the fan wins and the page loses.

• Browsers cap a single ArrayBuffer at roughly 1.5–2 GiB — measured, not theoretical.
• A 32-bit WebAssembly module can never address more than 4 GiB total, data included.
• Whole-file-in-memory designs multiply the archive size by two at exactly the wrong moment.

How this viewer does it: stream the archive, never hold it

ZIPTool's large-file path replaces "read the whole archive into memory" with "read the archive a slice at a time, from your own disk." The pieces are all standard web platform APIs, assembled so that no stage ever needs the complete file in RAM:

When a big RAR arrives, the browser first copies it into OPFS — the Origin Private File System, a private, sandboxed storage area the browser keeps on your local disk for the site you are on. It is not a server, not a cloud, not visible to other sites; it is your machine, managed by your browser. The copy happens once and streams in chunks, so memory stays flat.

The extractor then runs in a Web Worker and opens the staged copy with a synchronous file handle — the same primitive a native program uses. When the decompressor wants the next 64 KiB of the archive, the worker reads exactly that slice off your disk, straight into the small window of wasm memory the decompressor works in. A 4 GiB archive passes through a working set that never grows: we measured 16 MiB, flat, from the first entry to the last.

The decompressor itself is the official unrar 7.3.2 — the RAR extractor from the format's authors — compiled to WebAssembly and running locally in your tab. That is what makes the format coverage honest: RAR5 and RAR4 archives parse exactly the way the reference implementation parses them, because it *is* the reference implementation.

• The archive is staged once into OPFS — browser-local, per-site, never uploaded.
• A Web Worker reads slices on demand through a synchronous file handle, directly into the wasm window.
• Working memory stays at ~16 MiB regardless of archive size — measured on a 4.33 GiB file.
• Decompression is the official unrar 7.3.2 compiled to WebAssembly — the reference RAR extractor, running locally.

Measured on a real archive: 4.33 GiB, 1,134 photos

Not a synthetic benchmark: a real wedding shoot — one 4,648,486,424-byte RAR5 archive (4.33 GiB) holding 1,134 full-resolution JPEGs in a folder. This is the archive every step below was timed on, in Chrome, on an ordinary laptop:

The first open stages the file: a one-time local copy taking about half a minute, with a progress bar — the file is moving from your disk to your browser's private storage, not to the internet. After staging, the complete entry list of all 1,134 photos appears in about 15 milliseconds, because the worker reads headers by seeking, not by scanning. Clicking a photo extracts it in roughly 40 milliseconds per 3.6 MB image — the decompressor only ever touches the bytes of the file you asked for. Reopening the archive later is instant, because the staged copy is kept locally until you have been away for a while.

The same session proves the privacy property the blunt way: load the page, go offline, and keep working. Staging, listing, extraction — none of it notices the network is gone, because none of it uses the network. Your archive stays on your machine the entire time; see why client-side beats uploading for the full argument.

• 4,648,486,424 bytes (4.33 GiB) RAR5, 1,134 JPEGs — opened end-to-end in Chrome.
• One-time local staging: ~30 s with progress; entry listing after it: ~15 ms.
• Per-photo extraction: ~40 ms for a 3.6 MB image; working memory flat at 16 MiB.
• Everything above works offline after the page loads — nothing is uploaded, ever.

Large ZIP archives too

The memory fix is not RAR-specific. The fingerprinting step that used to read a whole file into one buffer now handles archives of any size, so multi-gigabyte ZIPs open as well — and ZIP needs no staging at all, because its own central directory already supports random access: the viewer reads the entry index from the end of the file without scanning the rest. The change is that the front door no longer has a two-gigabyte height bar.

Two shapes, both measured: a 4.6 GB zip with a single giant entry listed its contents in under a minute, and a 4.3 GB zip of a thousand photos listed all 1,000 entries in about 15 seconds — then extracted any single photo in roughly two. Browse a delivered photo library, pull the one file you need, close the tab; nothing uploaded at any point.

For RAR the streaming engine kicks in automatically from 1 GiB upward; smaller archives of every format keep using the standard in-memory path, which is faster when the file is small anyway. You never pick a mode — the viewer sizes the path to the file.

• Multi-gigabyte ZIPs browse with no staging at all — ZIP's central directory is random-access by design.
• Measured: 4.3 GB / 1,000 photos → full listing ~15 s, single-file extraction ~2 s.
• Big RAR files switch to the streaming path automatically at 1 GiB — no mode to choose.

Why the competition caps you at all

If you have already tried other online RAR openers with a big file, the pattern is familiar: a maximum-size error, a "please upgrade" prompt, or — worse — a progress bar that means your photos are being transmitted to someone's server. Neither is malice; both are architecture.

An upload-based tool hits *its* storage and bandwidth bills, so it caps you at whatever its budget allows — usually far below a serious archive. A client-side tool that loads the whole file into memory hits the browser ceilings described above, so it caps you slightly lower and calls it a limit. The only architecture with no natural size ceiling is the one where the file never moves and never has to fit in memory — which is the one this viewer uses, and the reason "4 GB" is not a special number here but simply the size of the archive we happened to test with.

• Upload-based tools cap sizes because storage and bandwidth cost money per byte — yours.
• In-memory web tools cap sizes because browsers cap allocations at ~2 GiB.
• A streaming, local-first design has no architectural size ceiling — the file stays on your disk.

The honest limits

Every capability claim on this site is bounded by what the tool actually does, so here is the other side of the ledger:

Browsing, listing, previewing and searching file names work at any archive size we have thrown at them. Extracting an individual file materializes that one file in memory, and the RAR streaming path enforces a 1 GiB per-entry cap with a clear message rather than a crash (an archive *of* many files is untouched by this; a single 5 GB video inside a rar is the case that waits for streaming extraction to disk). ZIP entries extract through the ordinary path, so individual files of normal size come out of a multi-gigabyte archive without ceremony — but one giant entry larger than a browser can hold in memory hits the same wall every in-browser tool hits, stated here so the boundary is explicit. Password-protected RAR archives are not supported — the viewer does not ask for, store, or process passwords for RAR, same as before. And the large-file path builds on OPFS synchronous file handles, a standard API shipped in current Chrome, Edge, Firefox and Safari 16.4+; on a browser without them you get a plain statement of that fact, and small archives keep working through the standard path.

• Browsing, listing, previews, name search: no size gate beyond your disk.
• Single-file extraction: up to 1 GiB per entry — honest error beyond, not a crash.
• Password-protected RAR: not supported (never was — no password prompts, no password storage).
• Large-file path needs OPFS sync handles: current Chrome/Edge/Firefox, Safari 16.4+; older browsers get a clear message.

How to verify none of this uploads your file

Do not take the privacy claim on faith — it takes ten seconds to check. Open your browser's developer tools, switch to the Network tab, and open your archive: you will see the page and its code load, and then nothing. No request carries your file. The staging copy, the entry list, every extracted photo — all of it happens between your disk and your tab.

The offline variant is even more convincing: load ZIPTool, turn on airplane mode, then drop the archive. Staging, listing and extraction proceed exactly as online, because "online" was never part of the pipeline. The same test on an upload-based tool ends with an error the moment the network drops — which is the difference between a privacy policy and an architecture.

• DevTools → Network: no request carries your archive — watch it stay empty while the file opens.
• Airplane mode after page load: everything still works; the network was never in the pipeline.

When you actually need this

The everyday cases where the big-file path earns its keep: a photographer culling one album out of a delivered 5 GB rar; a support engineer pulling a single log file out of a vendor's giant archive; a mod user inspecting a multi-gigabyte texture pack before committing to a full download; anyone on a metered or hostile network who cannot hand a private archive to a third-party server.

In all of these the shape of the work is the same: the archive is huge, the thing you need from it is small. Extraction-by-slice is built for exactly that — you read the table of contents, pull the two files you want, and the other 4 GB never leave your disk. Start on the RAR page, read the format background in what is a RAR file, or go straight to the RAR extractor for the whole-archive workflow.

• Pull one file out of a huge archive without extracting the rest — the fast path by design.
• Inspect before downloading: list a 6 GB mod pack's contents before committing.
• Metered or hostile network? The file physically cannot leave your machine.

Frequently asked questions