How to extract a file online - ZIP, RAR, 7z (which route on this site does what)

Last reviewed 2026-05-04. A direct routing rule for the search query "extract file online" / "file zipper" / "online file extractor". The reverse direction of the cycle-51 file-compressor routing guide: instead of "I have a folder, I want it zipped", you have a .zip / .rar / .7z archive and you want the files inside back in your browser. The honest answer depends on the file extension - and one of the three formats this site does not extract server-side. The guide names which route does what, and where to go for the formats this site does not handle.

Why "extract file online" usually means one of three operations

The phrase "extract file online" is one search query for three different reader-tasks. The first is "I have a .zip and I want the files inside" - the routine direction-inverse of zipping. The second is "I have a .rar or .7z and I want the files inside" - same goal, different archive container. The third is "I forgot the password to a .zip and I cannot open it" - which is not extraction at all but password recovery. Picking the right tool depends on which of those three you are in, and on this site the answer differs by extension.

The reason it matters: putting a .rar into a tool that only accepts .zip does not return an error message most readers find useful - it returns "wrong file type" or silently rejects the upload. And the time wasted re-uploading the same file does not change the answer. The four routing rules below cover the real cases, including what to do when this site does not have the extractor for your format - because it is more useful to read "open 7-Zip or Keka locally" than to keep clicking on a tool that does not handle the format.

Routing rule 1 - your archive is a .zip: open Unzip File (server-upload, optional password)

If the archive on your disk has the .zip extension, Unzip File is the route. Drop the file into the upload widget, the freetoolonline AWS service unzips the archive server-side, and the contents come back as a download. Concrete signals you are in this case:

• You received a .zip as an email attachment and your phone or work laptop does not have a desktop unzip tool handy. The browser tool returns the contents in one round trip.
• The .zip contains many files (a project folder, a batch of receipts, a folder of photos) and you want to inspect the contents before deciding what to keep. Unzip File returns the contained files; you save the ones you want.
• The .zip is password-protected and you know the password. Unzip File exposes a password input on the same flow - enter it when prompted and the extraction proceeds. The companion guide for the inverse direction (zipping a folder with a password) is How to zip a folder online step by step.

Reason: Unzip File is purpose-built for the .zip extraction reader-task. The accepted-file filter on the upload widget is .zip only - this is documented in the tool's source, and the guide makes the boundary explicit so you do not waste an upload on a file the route cannot handle. If your file is a .zip variant (.zipx) or a .zip wrapped inside another archive, see rule 3.

Routing rule 2 - your archive is a .rar or .7z: this site does not extract those server-side

If your archive on disk has the .rar or .7z extension, this site has no server-side extractor for those formats. There is no /unrar.html or /un7z.html route, and Unzip File's accepted-file filter is .zip only - uploading a .rar or a .7z to that route does not produce a useful result. The honest answer is: open the archive locally. Concrete routes by operating system:

• Windows: 7-Zip (free, open-source, handles .zip / .rar / .7z), WinRAR (.rar-native, free trial), or PeaZip (free, broad format support). Right-click the archive, "Extract to a folder", done.
• macOS: Keka (free / paid, App Store) or The Unarchiver (free, App Store) handle .zip / .rar / .7z. The macOS built-in Archive Utility opens .zip; for .rar / .7z you need one of the apps above.
• Linux: 7z x archive.7z (p7zip; apt install p7zip-full) for .7z, unrar x archive.rar (unrar; apt install unrar) for .rar.

Reason: writing "we extract RAR online" when the site has no .rar extractor is the kind of false claim that wastes the reader's time and breaks trust. The cycle-50 routing guide for ImageMagick names the same boundary for its own cluster ("if your task is video, ImageMagick is not the tool") - the rule generalises: when an online route does not exist for a format, the local-tool fallback is the right answer, and the guide is more useful when it says so directly. The companion comparison Online ZIP vs 7z vs RAR - which to pick walks through which format to choose when you control the producing side; this guide is for the consuming side (you already have the archive in front of you).

Routing rule 3 - mixed or non-obvious extension: pick by what the file actually is

The clean cases above cover most of the search query. The mixed cases need one extra question - what is the file actually? Concrete sub-cases:

• The extension says .zip but Unzip File rejects it: the file is mis-labelled (someone renamed a .rar to .zip) or the .zip is malformed. The diagnostic flow is in Recover corrupt ZIP file options - which lays out the three buckets (truly corrupt, mis-labelled, password-required-but-prompt-not-triggered).
• The file has no extension, or has .tar / .gz / .tar.gz / .bz2: this site does not have a TAR / GZIP route. The local-tool fallback from rule 2 applies - 7-Zip handles .tar.gz on Windows; tar -xzvf archive.tar.gz on macOS / Linux unwraps both layers in one step.
• The file is a .zipx (the WinZip variant): most desktop unzip tools handle .zipx (7-Zip, WinRAR, Keka) but this site's Unzip File accepts the standard .zip filter only - try it once; if it rejects the upload, fall back to a local tool.
• The "archive" is actually an installer (.dmg, .pkg, .msi, .exe): these are not archives in the same sense. Do not upload them to Unzip File. Open them with their native installer or use a desktop tool that knows the specific format.

Reason: the search query "extract file online" sweeps in archive formats that this site does not extract. Picking by what the file actually is (rather than by what the extension says) avoids the upload-and-fail loop. The companion guide ZIP vs ZIPx vs RAR vs 7z archive formats explained is the format-explainer; this guide is the operational routing rule.

Routing rule 4 - you forgot the password to a .zip: that is a different tool

If your .zip is password-protected and you do not know the password, do not keep trying to open it in Unzip File - the password input is for entering a known password, not for guessing. The closest route on this site is Remove ZIP Password, which is a different operation: it attempts to recover or strip the password protection from a .zip. Three caveats are worth saying directly:

• Recovery is not guaranteed. Strong passwords with modern AES-256 ZIP encryption are designed to be hard to break; the tool may return a "could not recover" result on intentionally strong passwords.
• Sensitive content should not be uploaded. The same privacy boundary that applies to Unzip File applies here - the file uploads to the freetoolonline AWS service and is processed server-side. If the .zip contains material you cannot upload (medical, legal, NDA), the local-tool fallback from rule 2 plus a local password-recovery tool is the right route, and rule 5 below names two desktop options.
• The companion guide PDF password types - owner vs user covers a related distinction for PDFs (owner-set vs user-set passwords); for .zip the distinction is simpler - either the password is set or it is not.

Reason: recovering a forgotten password is a different reader-task from "I have an archive, I want the contents". Naming the boundary keeps the routing rule clean: Unzip File for known-password and no-password ZIPs, Remove ZIP Password for forgotten-password ZIPs, local tools for everything else. The full ZIP-cluster overview is at ZIP Tools.

Routing rule 5 - the file is huge or sensitive: extract locally instead of uploading

Unzip File uploads your archive to the freetoolonline AWS service and the extraction runs server-side. That is the right path for almost every browser-tool reader-task, but two cases call for the local-tool fallback. First, very large archives (a multi-gigabyte project archive, a backup .zip in the gigabytes range) are slow to upload and slow to download even on a good connection - if you control a desktop machine, the OS-built-in or local-app extractor (rule 2) is faster end-to-end because the bytes never leave your disk. Second, files you cannot upload for confidentiality reasons (medical imaging, legal evidence, code under NDA) need to stay local - even when the file is small, the local tool is the right route.

The trade-off has the same shape as the equivalent decisions for compressing files (File Compressor Online: ZIP a folder vs Compress an image) and converting video / image files (FFmpeg online vs local FFmpeg - when each wins, ImageMagick online vs task-specific tools). The boundary is the same: online routes win on convenience for normal-size, non-sensitive inputs; local routes win on speed and privacy for huge or sensitive ones. For .zip extraction the cycle-51 file-compressor guide names the same boundary in the inverse direction (compress, not extract), and the full sitewide answer to the "no upload" question is in Free online tools that work without uploading files - Unzip File is not on that list, exactly because the extraction step runs on the server.

If the upload stalled or the output is wrong: troubleshoot before re-running

If Unzip File accepts your upload but no download appears within a couple of minutes, do not re-upload. Re-uploading the same file does not fix the underlying cause - it queues a second job that hits the same wall. The common stalls are: input-size limit hit on the upload (the archive is bigger than the per-file cap; rule 5 applies), browser tab refreshed during the convert pipeline (the result downloads to the closed tab and is lost), or a non-.zip input given to the .zip-only filter (rule 1 vs rule 2 was the wrong call - re-read the extension and route accordingly).

If the output is the wrong shape - for instance the .zip extracted but the files inside are themselves archives - that is a nested-archive case: extract the outer .zip first, then route each inner file by its own extension (a .rar inside a .zip is still a .rar and rule 2 applies). If the recipient cannot open the .zip you produced from the inverse direction (zipping a folder), they may need Unzip File in their browser, and if a password is in the way Remove ZIP Password covers the recovery flow. For everything else - one common operation, the right route by extension, the right fallback for huge or sensitive files - the answer takes 30 seconds; the wrong answer takes another minute of upload time you did not need to spend.