A ZIP archive (and a .jar, which is the same container) keeps a plain-text index of everything inside it, and that index is never compressed. So the names, sizes, folder structure and timestamps of every file are readable without extracting - or even decrypting - a single byte. That same central directory records which operating system built the archive and, on Unix, the exact account that created it.
Scan a ZIP & ZIP-based packages fileThe headline is the file listing. File X-Ray walks the ZIP central directory and shows every entry's name and folder path, the number of entries and the total uncompressed size. Because the listing is stored uncompressed, it is readable even when the entries themselves are password protected - encryption hides the contents of a file, not its name. Folder names such as "2024 payroll" or "client contracts" describe what is inside without anyone opening it, and any name that looks sensitive on its own is flagged.
Two fields point back at the machine that made the archive. "Built On" reads the version-made-by byte on each entry to name the host operating system (MS-DOS/Windows FAT, Unix, macOS, Windows NTFS). On Unix-built archives, an Info-ZIP extra field can also carry the real numeric user and group id of the account that created it - uid 1000 is the primary user on a personal Linux box, and on a server these values identify a specific account. A __MACOSX folder, added by the macOS Finder's Compress command, confirms the archive was made on a Mac.
ZIP timestamps are unusually revealing about time zone. The standard modification date is stored in MS-DOS format, which has no time zone at all, so the value is the creator's local wall clock rather than UTC and hints at where they work. When present, the NTFS (0x000A) or extended-timestamp (0x5455) extra fields add high-precision creation and last-access times in UTC, dating when each file first existed and when it was last opened.
On the security side, File X-Ray reports whether any entries are encrypted and which scheme they use - strong WinZip AES versus the legacy ZipCrypto, which is weak and crackable. It also flags "unsafe paths": entries using absolute paths or ../ parent references. That is the Zip Slip pattern, which can write files outside the folder you extract into, and it can also leak the original absolute location the files came from.
A great many formats are a ZIP with a different extension, and File X-Ray names them rather than calling everything an archive: a Java jar, a Python wheel, an InDesign IDML, a Sketch document, a Krita image and an Adobe XD file are all read here. For four of them the scan goes past the listing and opens the one entry inside that carries a person.
A Python wheel is the clearest case. Its dist-info/METADATA file records the author name, the author email address, the project home page and the licence, and its WHEEL file records the exact build tool and version that packaged it. Nothing in a normal install shows you any of that, and it travels with every copy of the package. A Java jar is the same shape: META-INF/MANIFEST.MF carries the JDK build string, and where the build tool wrote one, a Built-By line naming the account of whoever compiled it.
An IDML carries the XMP that InDesign wrote, which names the exact application build and the document and instance identifiers that let two exported files be tied back to one source document. A Sketch file records the application version, build number and source commit it was saved from.
This is a selection. The full field manual documents the fields read from each format.
The central directory holds the name, size and folder path of every entry, its modification timestamp, and the operating system that wrote it. Depending on how it was made it can also carry Unix user and group IDs, high-precision NTFS creation and access times, and the encryption scheme used - all readable without extracting anything.
Yes. The listing lives in the central directory, which is stored uncompressed and unencrypted. A ZIP password encrypts the contents of each file, not its name, size or timestamp, so the full listing is visible even for a locked archive. File X-Ray reads it entirely in your browser.
It can. Every entry records the host operating system, a __MACOSX folder shows it was zipped on a Mac in the Finder, and Unix-built archives may embed the creator's numeric user and group ID. The MS-DOS timestamps are also the creator's local clock, hinting at their time zone.
An entry whose name is an absolute path or uses ../ to point outside the extraction folder. When such an archive is unpacked carelessly it can overwrite files elsewhere on disk, which is the basis of directory-traversal attacks; the path can also leak the original absolute location of the files.
File X-Ray cleans the archive itself: it removes every entry's modification timestamp, the NTFS and Info-ZIP extra fields that repeat those timestamps at higher precision, the Unix user and group IDs, any per-file comments, and the archive comment. The compressed data is copied across untouched, so nothing is re-compressed and an encrypted entry still opens with its password. Two things it deliberately does not do. It does not open the files inside, so a photo in the archive keeps its own GPS coordinates and camera serial - clean those files first, then zip them. And it does not change file or folder NAMES, because a ZIP's listing is its contents; if the names themselves are sensitive, rename them before zipping. The Finder's __MACOSX folder is a real entry, not metadata, so it also stays.
Yes, in almost every case. Packaging writes the author name, email, home page and licence into a METADATA file inside the wheel, and it stays there for every copy that is ever downloaded. Installers do not show it, so most maintainers never think about it. Drop a .whl here and it is read out for you.
META-INF/MANIFEST.MF records the JDK version and vendor that compiled the archive, and build tools such as Maven and Ant often add a Built-By line containing the account name of the person who ran the build. It can also carry the OSGi bundle identity and the entry-point class.
Because both are ZIP archives with a different extension. File X-Ray recognises them by name and by their contents, lists what is inside, and then reads the specific file each format uses to record its own metadata: the XMP in an IDML, and meta.json in a Sketch document.
File X-Ray reads ZIP & ZIP-based packages files entirely in your browser - the file never leaves your device. For this format you can also download a clean copy with the metadata removed. Scan a file now.