How to prefix remover vs unzip -j, zip, and tar --strip-components
- Step 1Decide what you actually want to remove — If you want to drop a single wrapping folder and keep the inner tree, the prefix remover (or
tar --strip-components=1) is right. If you genuinely want every file in one flat folder with no subdirs, that isunzip -j— a different operation. - Step 2Pick by format — For ZIP, TAR and GZIP, the CLI tools are everywhere. For 7z, RAR or ISO without installing 7-Zip/unrar, the browser tool reads them via libarchive WASM and re-flattens.
- Step 3Pick by privacy and access — On a corporate laptop with no admin rights, the browser tool runs without installing anything; nothing leaves the tab. A local CLI is equally private but needs the binary present.
- Step 4Run the browser path — Open the Path Prefix Remover, drop the archive, leave Prefix to strip empty to auto-detect or type one, then Process.
- Step 5Mind the output type — The browser tool always emits a ZIP. If you need the original format (e.g. TAR.GZ back), run the archive format converter afterward — the CLI keeps the source format.
- Step 6Make it reproducible — The CLI lets you control timestamps with flags; the browser tool re-zips with rebuild timestamps. For deterministic output, follow with the timestamp normalizer.
Prefix Remover vs CLI equivalents
Behaviour comparison for the common task: remove one wrapping folder while keeping the inner directory tree.
| Aspect | JAD Path Prefix Remover | tar --strip-components=N | unzip -j | cd + zip -r |
|---|---|---|---|---|
| Install needed | None (browser) | tar present on most systems | Info-ZIP unzip | Info-ZIP zip |
| Keeps subdir tree | Yes | Yes | No — junks all paths | Yes |
| Auto-detect the wrapper | Yes (single top folder) | No — you supply N | n/a | Manual |
| Reads 7z / RAR / ISO | Yes (libarchive WASM) | No | No | No |
| Output format | Always ZIP | Same as input (tar) | ZIP/files | ZIP |
| Privacy | Stays in browser tab | Local | Local | Local |
Common footguns, side by side
Where each path silently does the wrong thing — and what the prefix remover does instead.
| Situation | CLI behaviour | Path Prefix Remover behaviour |
|---|---|---|
| Wrong strip count | --strip-components=2 on a one-level wrapper silently deletes real files | Strips only entries matching the exact prefix; non-matching paths are untouched |
| Multiple top folders | --strip-components=1 mangles every branch | Stops with "No common top-level prefix detected" unless you name one |
| Want subdirs kept | unzip -j flattens everything into one folder | Preserves the inner tree below the stripped prefix |
| 7z / RAR source | Needs 7z / unrar installed | Reads it directly, no extra binary |
Cookbook
Concrete before/after comparisons so you can see exactly where the browser tool and the CLI diverge on the same archive.
Same job, two tools — strip one wrapper
Removing the single top folder from a tarball. tar --strip-components=1 and the prefix remover produce the same logical tree; the browser output is a ZIP.
CLI: tar --strip-components=1 -xzf my-app-1.4.0.tar.gz # files extracted flat, original tar.gz untouched Browser: Drop my-app-1.4.0.tar.gz, Prefix to strip = empty, Process Download: my-app-1.4.0-flattened.zip (ZIP, paths flattened)
Why unzip -j is NOT the same
unzip -j discards all directory structure, not just the wrapper. The prefix remover keeps subfolders below the stripped prefix.
Archive contents: app-1.0/src/index.js app-1.0/src/util/log.js unzip -j app-1.0.zip -> index.js, log.js (both in one folder — collision risk) Prefix Remover (auto) -> src/index.js, src/util/log.js (tree preserved)
Multiple top folders: CLI mangles, tool stops
With two top-level directories, blindly stripping one level corrupts paths. The prefix remover refuses unless you name the prefix.
Archive contents: frontend/app.js backend/server.js tar --strip-components=1 -> app.js, server.js (folder names lost, possible collisions) Prefix Remover (empty) -> Error: No common top-level prefix detected Prefix Remover (frontend/) -> app.js (frontend stripped), backend/server.js kept
Reading a 7z without 7-Zip installed
Standard unzip/tar cannot open a 7z. The browser tool reads it via libarchive WASM and re-flattens to ZIP.
CLI: unzip release.7z -> error: not a zip file (needs: 7z x ... — separate install) Browser: Drop release.7z, Process -> release-flattened.zip
Rebuilding a reproducible ZIP
CLI lets you pin timestamps with flags; the browser tool re-zips with rebuild times. Chain the timestamp normalizer for determinism.
CLI (deterministic): TZ=UTC zip -rX -D out.zip . # -X strips extra metadata Browser (two steps): 1) Path Prefix Remover -> flattened.zip 2) Timestamp Normalizer (fixed 1980-01-01) -> deterministic.zip
Edge cases and what actually happens
Output format differs from input
By design (always ZIP)Unlike tar, which keeps the source format, the browser tool always writes a ZIP. If a downstream step expects TAR.GZ, convert with the archive format converter after flattening.
unzip -j collision
Avoided hereunzip -j flattens two same-named files in different folders onto one name, silently overwriting one. The prefix remover keeps the inner tree, so a/x.txt and b/x.txt stay distinct.
Strip count too high on CLI
Error avoided heretar --strip-components=2 on a single-level wrapper deletes real top files. The prefix remover only removes an exact matching prefix, so it never eats unrelated path segments.
File over the tier cap
Rejected (tier limit)The CLI has no size limit; the browser tool does — 50 MB Free, 500 MB Pro, 2 GB Pro-Media and Developer. For multi-GB archives the CLI is the better fit.
RAR archive
Supported (read-only)libarchive reads RAR in the browser, so the tool flattens it to ZIP without unrar installed. It does not write RAR — no browser library can.
Encrypted ZIP
Supported (read via zip.js)Encrypted entries are read through zip.js; the rebuilt ZIP is unencrypted. The CLI would prompt for a password and could keep encryption — re-encrypt with the encrypted ZIP creator if needed.
Need to script thousands of archives
Use CLIThere is no API yet, and the tool processes one archive per job. A shell loop with tar --strip-components is the right tool for batch automation across many files.
Multiple top folders, empty prefix
Stopped — no prefix detectedThe tool will not guess. Name the exact prefix to strip; the CLI would happily strip a level and risk path collisions.
Reproducible build requirement
Two-step hereThe CLI can pin timestamps inline. The browser path needs a second pass through the timestamp normalizer because the re-zip uses rebuild times.
ISO image input
Supported (read-only)libarchive can read ISO 9660 images, so you can flatten a directory wrapped inside an ISO into a ZIP — something neither unzip nor tar does out of the box.
Frequently asked questions
Is the browser tool slower than the CLI?
For files under ~100 MB the difference is negligible — fflate is fast. For multi-GB archives the CLI wins because it streams from disk, while the browser is bounded by tab memory and the 2 GB tier cap.
Are the outputs interchangeable?
Yes for ZIP — the browser tool writes a standard ZIP openable by unzip, 7-Zip or any consumer. The difference is format: the tool always outputs ZIP, while tar keeps the source format.
When should I prefer the browser tool?
One-off jobs, machines where you cannot install software, archives in formats your shell can't open (7z, RAR, ISO), and any time you want to avoid unzip -j collisions or a wrong --strip-components count.
When should I prefer the CLI?
Archives over 2 GB, scripted pipelines and CI, batch processing of many files, and workflows where you need to preserve the original archive format inline.
Why does unzip -j give a different result?
-j junks ALL paths, flattening every file into one folder, not just the wrapper. The prefix remover removes only the shared top-level prefix and keeps the inner directory tree.
Does the tool write 7z or RAR?
No. It reads 7z and RAR via libarchive WASM, but the output is always a ZIP — no in-browser library can write true 7z or RAR.
Can I keep the original timestamps?
The re-zip uses rebuild timestamps. For deterministic or original-like timestamps, run the timestamp normalizer on the flattened ZIP.
Is my data uploaded?
No. Like a local CLI, everything runs locally — in this case in your browser tab via WebAssembly. No archive bytes leave your machine.
What about huge archives the browser can't hold?
The tier cap is 2 GB. Beyond that, use the CLI. For the narrow case of building a very large ZIP from local files, the streaming ZIP builder avoids RAM spikes, but it builds rather than flattens.
Does the tool need the trailing slash in the prefix?
Match what you see in the entry paths. Auto-detect adds the trailing slash for you; when typing a prefix manually, include the slash (e.g. src/) so it matches src/... and not a file literally named src.
Can I flatten an archive inside an archive?
This tool reads one archive level. For archives nested inside archives, run the nested archive extractor first, then flatten the result.
Is there a JAD wrapper or metadata in the output?
No. The output is a plain ZIP with no proprietary headers — identical in structure to one produced by any standard ZIP tool.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.