Archive Metadata Extractor Online for Free

Tell who built the ZIP from hostOS

The high byte of versionMadeBy identifies the creating system. A Unix-built ZIP carries hostOS 3 (and usually permission bits in extra fields); a Windows/NTFS one carries 11; a DOS/FAT one carries 0. This is the field that explains why some ZIPs preserve chmod and others lose it.

Report excerpt for a ZIP built on Linux:
{
  "archive": "build.zip",
  "totalEntries": 2,
  "entries": [
    {
      "name": "run.sh",
      "versionMadeBy": 798,
      "hostOS": 3,
      "versionNeeded": 20,
      "flags": { "encrypted": false, "utf8": true, "dataDescriptor": false },
      "compressionMethod": "Deflate",
      ...
    }
  ]
}

hostOS 3 = Unix. A Windows-built ZIP of the same files would show hostOS 11 here.

Spot encrypted entries without the password

flags.encrypted comes from general-purpose bit 0, which lives in plaintext in the central directory — so you can see which entries are encrypted without ever decrypting anything. AES entries also report compressionMethod 'AES'.

{
  "name": "secret.docx",
  "flags": { "encrypted": true, "utf8": false, "dataDescriptor": false },
  "compressionMethod": "AES",
  "crc32": "00000000"
}

→ Encrypted. To test a candidate password use
  /archive-tools/archive-password-tester ;
to classify ZipCrypto-vs-AES across the whole archive use
  /archive-tools/encrypted-archive-detector .

Find non-UTF-8 filenames before they mojibake

When flags.utf8 is false, the filename was stored in a legacy OEM/ANSI code page. The tool still decodes the bytes as UTF-8 (non-fatal), so a name with accents may come back with U+FFFD replacement characters. The flag is your signal that the name needs code-page handling on extraction.

{
  "name": "r\uFFFDsum\uFFFD.pdf",
  "flags": { "encrypted": false, "utf8": false, "dataDescriptor": false }
}

utf8: false → the original was likely 'résumé.pdf' stored as CP-1252.
The \uFFFD marks bytes that are not valid UTF-8. To clean such
names on extraction, see /archive-tools/filename-sanitizer .

Read the stored timestamp of every entry

lastModified is the MS-DOS date/time pair decoded to a local Date, then serialised with toISOString() (UTC). DOS timestamps have 2-second granularity and no timezone, so seconds are always even and the wall-clock interpretation is the builder's local time.

{ "name": "app.js", "lastModified": "2026-05-04T13:22:14.000Z" }
{ "name": "app.css", "lastModified": "2026-05-04T13:22:14.000Z" }

All-identical timestamps usually mean a reproducible build.
To force a fixed timestamp on output, use
  /archive-tools/timestamp-normalizer (default 1980-01-01).

Audit compression ratio from the raw sizes

Each entry reports compressedSize and uncompressedSize straight from the central directory. Divide to get the per-entry ratio. The report does not compute the ratio for you — that is what the ratio calculator is for — but the inputs are right here.

{ "name": "data.csv",  "compressedSize": 18234, "uncompressedSize": 142998 }
  → 18234 / 142998 = 0.127  (compressed to ~13%)

{ "name": "photo.jpg", "compressedSize": 482100, "uncompressedSize": 484992 }
  → already entropy-dense; barely shrinks.

For a full per-file ratio breakdown without doing the math by hand:
  /archive-tools/compression-ratio-calculator .

This tool parses the ZIP central directory only — it does not use the libarchive WASM bridge. If findEocd cannot locate the End Of Central Directory signature, parsing returns zero entries and the tool throws 'Not a valid ZIP archive (or unsupported format for metadata extraction).' A renamed .rar/.7z/.tar.gz hits this. Run /archive-tools/auto-format-detector to confirm the real format first.

An archive whose central directory contains no entries also produces an empty entries array, so the same 'Not a valid ZIP archive…' error is thrown. The check is entries.length === 0, which cannot distinguish 'not a ZIP' from 'an empty ZIP'. There is nothing to report for an entry-less archive.

Before processing, the client checks file.size against the tier ceiling and throws 'File "<name>" exceeds the <tier> tier per-job limit (<size>). Upgrade for larger files.' Free is 50 MB, Pro 500 MB, Pro-media and Developer 2 GB. The cap is on file bytes; the separate 500-entry (free) / 50,000 (pro) entry ceiling is enforced by the tier schema.

Encryption does not block metadata extraction. The central directory is never encrypted, so names, sizes, timestamps, methods, and flags.encrypted all read normally. Only the entry payloads are encrypted, and this tool never touches payloads. AES entries report compressionMethod: 'AES' and a crc32 of 00000000.

If a method code is not in the known list (Stored, Shrunk, Imploded, Deflate, Deflate64, BZIP2, LZMA, XZ, PPMd, AES), compressionMethodName() returns the literal string Method N with the raw code. The entry is still reported in full — nothing is dropped.

Because findEocd scans backwards from the end of the file for the EOCD signature, a self-extracting archive (an executable stub followed by a ZIP) is read correctly — the central directory still sits near the end. The stub bytes are ignored.

The report tells you hasComment: true / hasExtraField: true per entry but does NOT include the comment text or extra-field contents. To read the global archive comment use /archive-tools/comment-extractor; per-entry comments are surfaced there too. This tool reports presence, not payload, for those two fields.

Names are decoded with TextDecoder('utf-8', { fatal: false }), so byte sequences that are not valid UTF-8 are replaced with U+FFFD (the replacement character) rather than throwing. Combined with flags.utf8: false, a U+FFFD in a name is your signal that the original used a legacy code page.

The entry count is read from the 16-bit EOCD field, which maxes out at 65,535. A ZIP64 archive with more entries than that will report a wrapped totalEntries and the loop stops early. Most real archives are far below this; if you suspect a giant ZIP64 archive, verify the entry count with another tool. The free/pro entry caps (500 / 50,000) keep typical inputs well within range.

The parser advances entry-by-entry and stops the moment a record does not start with the central-directory signature 0x02014b50. A truncated directory therefore yields a partial report (whatever parsed before the break); a directory damaged before the first entry yields zero entries and the 'Not a valid ZIP archive…' error. Run /archive-tools/corrupted-zip-repair to attempt recovery.