ByteScope

Extract Archive

Unpack zip, rar, 7z and tar.gz right in the browser — passwords stay local, and dangerous paths are stopped at the door.

Archives are opened, decrypted and unpacked entirely in this tab — nothing is uploaded, and the password never leaves the page.

Drop an archive here

or click to browse — zip · 7z · rar · tar · tar.gz · tar.bz2 · tar.xz · tar.zst · gz (7z, rar and the bzip2 / xz / zstd formats load a one-time WebAssembly decoder)

Browser Support Matrix

Reading an archive and downloading a zip work in every browser. Writing straight into a folder does not.

FeatureChromeEdgeFirefoxSafari
Reading zip / tar / tar.gz / gzSupportedSupportedSupportedSupported
Download one file, or a repacked zipSupportedSupportedSupportedSupported
7z and rar (libarchive in WebAssembly)Works in every modern browser; downloads about 500 KB the first time you open a 7z or rar.SupportedSupportedSupportedSupported
Write into a folder you pickFile System Access API — Chromium on desktop only. Not Firefox, not Safari, and not Chrome or Edge on Android.Partial supportPartial supportNot supportedNot supported
Password-protected archivesThe password is passed to the same WebAssembly engine, which is what decrypts zip, 7z and rar. Not yet verified against a real encrypted archive of any of the three.UntestedUntestedUntestedUntested

Detected in this browser:

  • showDirectoryPicker Untested
  • secure context Untested

About this tool

Drop in a zip, 7z, rar, tar, tar.gz, tar.bz2, tar.xz, tar.zst or plain gz file and take the contents out, entirely in your browser. RAR and 7z are handled by libarchive compiled to WebAssembly — the same engine behind desktop extractors, not a half-finished JavaScript port. You get a file tree of everything inside: download one file, tick several and save them as a zip, or extract the lot. On Chromium browsers you can even write straight into a folder you pick, via the File System Access API, so nothing takes a detour through the Downloads folder; other browsers get the same content repacked as a single zip.

Passwords that never leave your machine

For an encrypted archive, type the password and it decrypts locally — there is no server in the path, so there is literally nowhere for the password or the file to go. That is what makes this usable on material you would never upload to a website: a client's deliverable, a password-protected backup, a disclosure package, an archive pulled off a machine that never touches the internet. One honest limit: everything happens in memory, so RAM sets the ceiling — fine for everyday archives, but multi-gigabyte ones will struggle, and there is a hard size cap.

Checked before it touches your disk

An archive is a list of file names that someone else wrote — and nothing stops one of those names from being ../../.ssh/authorized_keys. Extract that naively and it writes outside the folder you chose; this zip-slip trick has been catching real extractors for twenty years. Here, every entry's path is resolved before a single byte is written, and entries that try to escape are refused and listed by name, not silently dropped onto your disk. The declared uncompressed size is also added up first, so a decompression bomb — a 42 KB zip claiming to expand into petabytes — is caught before your disk is.

Frequently asked questions

Is my archive uploaded anywhere?

No. Opening, decrypting and unpacking all happen in WebAssembly code running in your browser; no server ever sees the file. You don't have to take that on faith: open DevTools, switch to the Network tab, and extract an archive — no request carries your file. You can even load the page, go offline, and extraction keeps working.

How big an archive can it handle, and why is my RAR slow?

Everything runs in memory, so the limit is your device's RAM, not your disk — there is a hard size cap, hundreds of megabytes are usually fine on a desktop, and multi-gigabyte archives are where things get tight. Speed is a separate matter: solid RAR archives and some exotic 7z filters compress all files as one continuous stream, so pulling out even a single file forces the engine to decode everything before it. That slowness is a property of the format, not of the tool.

Can it extract password-protected archives?

That is what the password field is for: what you type is handed straight to the libarchive WebAssembly engine, which is the same code that decrypts zip, rar and 7z on the desktop, and it runs on your machine — the password is never transmitted, because there is no server to transmit it to. Being straight with you about how far that has been checked: the mechanism is wired up and a wrong password produces a clear error rather than corrupted files, but it has not yet been verified against a real encrypted archive of each type, and AES-256 zip in particular may not decode at all. The support matrix marks that row untested for exactly this reason. It is still the practical difference from the Archive Inspector next door, which does not attempt decryption at all.

Why don't I see the option to extract into a folder?

Writing directly into a folder you pick uses the File System Access API, which currently exists only in Chromium browsers — Chrome, Edge, Opera. Firefox and Safari don't implement it, so there you get the same result by a slower route: everything is repacked into one zip and downloaded. Same files, one extra unzip step.

What happens if the archive contains something dangerous?

Two specific attacks are checked before anything is written. Entries whose paths climb out of the target folder — the ../../.ssh/authorized_keys trick — are refused and listed by name, so you can see exactly what the archive attempted. And the total declared uncompressed size is computed first, so a decompression bomb is rejected before it fills your memory. What this is not is malware scanning: an extracted file can still be malicious in its content, so treat the output of an untrusted archive with the same care as any download.