How to troubleshooting the timestamp normaliser
- Step 1Read the exact error or metric shown — The tool surfaces a specific message (
Invalid target timestamp.,Could not detect or extract archive format, a tier-limit prompt) or result metrics (Timestamp, Entries). Note which one you got — the fix depends on it. - Step 2Check the file is a real, supported archive — Supported: ZIP, TAR, gz, tar.gz/tgz, bz2, tar.bz2, xz, tar.xz, 7z, RAR, ISO. If the file is truncated or not actually an archive, format detection fails. Verify it opens in another tool before retrying.
- Step 3Check it isn't encrypted — If the ZIP has encrypted entries, the normaliser can't read it (no password option). Confirm with encrypted-archive-detector; if encrypted, decrypt first via multi-format-extractor.
- Step 4Check the size and entry count against your tier — Free is 50 MB / 500 entries. A folder of many tiny files can blow the entry cap while staying under 50 MB. If you hit a cap, trim the archive or upgrade (Pro: 500 MB / 50,000; Developer: 2 GB / 500,000).
- Step 5Confirm the 'problem' isn't expected behaviour — ZIP output from a tar.gz input, a different output size, and missing empty folders are all intended. If that's your issue, it's not a bug — see the edge cases for the matching sibling tool.
- Step 6If it stalls, reduce load or use the runner — A very large archive re-zipping in the tab can feel slow. Close other heavy tabs, disable WASM-blocking extensions, or on Pro+ let the @jadapps/runner (headless Chromium) handle the job.
Symptom to cause to fix
The common failure and surprise modes, each with its real cause and the action to take.
| Symptom | Likely cause | Fix |
|---|---|---|
Invalid target timestamp. | Date value couldn't be parsed (usually via automation) | Pass a valid YYYY-MM-DD; the UI picker always does |
Could not detect or extract archive format | Not an archive, truncated, or unsupported | Verify the file; repair with corrupted-zip-repair if damaged |
| Run fails on a ZIP | Encrypted entries (no password field) | Decrypt via multi-format-extractor first |
| Upgrade prompt before processing | Over 50 MB or over 500 entries (Free) | Trim the archive or upgrade tier |
| Output is .zip, not my format | Tool always outputs ZIP | Convert with zip-to-tar-gz if needed |
| Empty folders missing | Only file entries are re-packed | Recreate dirs after extraction |
| Output size differs | Re-compressed at DEFLATE level 6 | Expected — compare hashes, not sizes |
| Feels stuck / slow | Large archive in-browser, or WASM blocked | Reduce size, disable extensions, use runner (Pro+) |
Tier caps that cause rejections
Both limits are enforced. Watch entry count for archives full of small files.
| Tier | Max size | Max entries | Files per run |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro + Media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | unlimited |
Is it a bug or expected?
Behaviours people mistake for bugs. All are by design.
| Observation | Verdict |
|---|---|
| A tar.gz came back as a .zip | Expected — output is always ZIP |
| All files show the same date/time | Expected — that's the whole point |
| Time shows 00:00 UTC, not what I set | Expected — date-only picker |
| Output bytes/size changed | Expected — re-compressed to level 6 |
| An empty folder is gone | Expected — empty-dir entries dropped |
| Original timestamps lost | Expected — they are overwritten |
Cookbook
Walkthroughs for the errors people actually hit, with the message and the resolution.
Invalid target timestamp
Seen mainly when a malformed date is supplied via automation. The processor builds a Date from the string; if it's not a real date, it throws.
targetTimestamp: "2026-13-40" (bad month/day) -> throws: Invalid target timestamp. Fix: use a valid calendar date, e.g. 1980-01-01 or 2026-06-10. The in-app date picker can only emit valid YYYY-MM-DD.
Could not detect or extract archive format
The file's magic bytes don't match any supported archive and a fallback ZIP parse also failed. Usually a renamed non-archive, a truncated download, or a corrupt file.
Input: report.zip (actually a half-finished download)
-> Could not detect or extract archive format for report.zip
Fix:
- Re-download / verify the file is complete
- If genuinely corrupt: /archive-tools/corrupted-zip-repair
then re-run the normaliser on the repaired outputEncrypted ZIP can't be normalised
The normaliser has no password field, so any encrypted entry stops the read. Detect, then decrypt with the right sibling first.
1. /archive-tools/encrypted-archive-detector -> 'AES-256 encrypted'
2. /archive-tools/multi-format-extractor (enter password)
-> extracts plaintext files
3. Re-zip / drop the extracted set into timestamp-normalizer
-> now succeedsHit the 500-entry cap under 50 MB
A small archive full of tiny files trips the entry cap even though the size is fine. The message points at the limit, not the size.
node_modules.zip -> 41 MB but 9,400 entries -> Free cap is 500 entries -> rejected with upgrade prompt Fix: upgrade (Pro = 50,000 entries), or prune the archive (e.g. /archive-tools/empty-folder-pruner, selective tooling).
Output ZIP smaller/larger than the input — not a bug
Because the tool re-compresses at DEFLATE level 6, a store-level input shrinks and a tightly-packed input may grow slightly. Contents are unchanged.
input build.zip (stored, level 0) 12.0 MB output build-normalized.zip (DEFLATE 6) 4.3 MB Contents identical; only container compression changed. Verify with /archive-tools/archive-diff (0 changed files).
Edge cases and what actually happens
`Invalid target timestamp.`
Invalid date errorThrown when the supplied date can't be parsed into a real Date. The in-app date picker only emits valid YYYY-MM-DD, so this almost always comes from an automation/runner path passing a malformed string. Pass a valid calendar date.
`Could not detect or extract archive format`
Format errorThe magic bytes match no supported format and the last-resort ZIP parse failed. Causes: not an archive, truncated download, or corruption. Verify the file opens elsewhere; if corrupt, repair with corrupted-zip-repair first.
Encrypted entries reject the read
FailThe normaliser exposes no password input, so a ZIP with AES-256 or ZipCrypto entries can't be opened. Detect with encrypted-archive-detector, decrypt via multi-format-extractor, then normalise the plaintext.
Over the size cap
Tier limitFree rejects archives over 50 MB before processing. Pro allows 500 MB, Pro + Media / Developer 2 GB. The check is on the input archive's byte size.
Over the entry cap
Tier limitSeparate from size: Free caps at 500 entries, Pro at 50,000, Pro + Media / Developer at 500,000. A node_modules-style archive can hit this well under the size cap, so the message will cite entries, not megabytes.
Output is a ZIP, not the input format
ExpectedWhatever you drop, you get <name>-normalized.zip. If you expected a tar.gz or 7z back, that's not a failure — convert with a sibling such as zip-to-tar-gz.
All entries share one date/time
By designEvery entry is stamped to the single chosen date at 00:00:00 UTC. If you wanted to keep per-file times, this is the wrong tool — its purpose is to flatten all times to one canonical value.
Empty folders disappeared
Not preservedExtraction keeps only file entries, so empty-directory records are dropped. Files inside folders keep their paths; only standalone empty-folder markers are lost. Recreate them after extraction if needed.
Output size changed unexpectedly
ExpectedThe tool re-compresses at DEFLATE level 6, so the output size will differ from the input even though file contents are byte-identical. Compare content hashes (or use archive-diff), not raw sizes.
Processing seems stuck
PerformanceAll work runs in your browser tab. A large archive being extracted and re-zipped by fflate/libarchive WASM can take time and pin a CPU core. Close heavy tabs, ensure no extension blocks WebAssembly, and on Pro+ let the @jadapps/runner handle it.
Frequently asked questions
Why do I get 'Invalid target timestamp.'?
The date string couldn't be parsed into a real Date. The in-app date picker can only produce valid YYYY-MM-DD, so this usually means an automation/runner path passed a malformed value. Use a valid calendar date such as 1980-01-01.
Why does it say it can't detect or extract the format?
The file's magic bytes don't match any supported archive and a fallback ZIP parse failed — typically a renamed non-archive, a truncated download, or corruption. Verify the file opens in another tool; if it's genuinely damaged, repair it with corrupted-zip-repair first.
Why won't it process my password-protected ZIP?
This tool has no password field, so it cannot read encrypted entries. Detect encryption with encrypted-archive-detector, extract with the password via multi-format-extractor, then normalise the extracted, re-zipped files.
I got an upgrade prompt — which limit did I hit?
Either size or entry count. Free allows 50 MB and 500 entries. A small archive with thousands of files (like node_modules) trips the 500-entry cap while under 50 MB. Pro raises both to 500 MB / 50,000; Developer to 2 GB / 500,000.
Why did my tar.gz come back as a .zip?
The normaliser always outputs ZIP, regardless of input. That's expected, not an error. If you need tar.gz, convert afterward with zip-to-tar-gz.
Why is the output a different size than the input?
It re-compresses everything at DEFLATE level 6, so a store-level input shrinks and a differently-tuned input may change size — while the file contents stay byte-identical. Compare content (hash or archive-diff), not the raw size.
Where did my empty folders go?
Extraction keeps only real file entries, so empty-directory markers are dropped from the output. Folders containing files keep their paths; only standalone empty folders are lost. Recreate them after extraction if your workflow needs them.
Why do all my files show the same date?
That is exactly what the tool does — it sets every entry's modification time to the one date you picked (at 00:00:00 UTC). If you wanted per-file times preserved, this tool isn't the right choice; it canonicalises to a single value by design.
Why can't I set the time of day?
The control is a date-only picker, and the chosen date is applied as 00:00:00 UTC. There is no hour/minute field, so every entry lands at midnight UTC of the selected date.
It's stuck on 'processing' — what do I do?
Processing runs in your browser, so a large archive can take a while and load a CPU core. Close other heavy tabs, make sure no extension is blocking WebAssembly, and try a smaller archive to confirm. On Pro+, offload to the @jadapps/runner (headless Chromium).
Can I automate it to avoid these UI errors?
There's no public REST run endpoint for archive tools (apiAvailable: false). Pro+ tiers can offload execution to the paired @jadapps/runner, but for unattended pipelines a native strip-nondeterminism step is often simpler. If you do drive it programmatically, always pass a valid YYYY-MM-DD.
Nothing's wrong but I'm not sure it worked — how do I verify?
Check the result metrics: it reports the applied Timestamp (ISO) and the Entries count. Then hash the output with checksum-generator and re-run on the same input — identical hashes confirm a deterministic, successful normalisation.
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.