Binary & Archive Forensics - Free Online File Signature, Entropy, Hex & Archive Structure Analyzer
Binary & Archive Forensics
Identify any file by its magic bytes, find files hidden inside it, spot packed or encrypted regions, and compare files byte-by-byte. Drop an archive and its container structure is read as well - entries, integrity, anomalies and nested archives - without uploading anything.
Drop any file here
Archives (.zip .tar .gz .bz2 .xz .7z .rar) also get their structure read - or click to browse from your device
Choose fileWhat gets analysed
- Any file - identification by magic bytes, carved embedded files, byte entropy, ZIP index integrity, a hex viewer with two-file diff, and strings.
- Archives - ZIP, TAR, GZIP, BZIP2, XZ, 7z and RAR additionally get their entries, central-directory integrity, anomalies (zip-slip, bombs, disguised types), nested archives and an extract-and-hand-off tab.
The file's own bytes decide; the extension is only a fallback. Load a file to see its analysis tools here.
Archive Overview
What kind of archive this is, how many entries it declares, and what stands out about the way it was built.
Entries
Every entry this archive declares, in its own order - real compression method, encryption, timestamps and flags read straight from the format's own headers, not guessed from a file extension.
Central Directory vs. Local Headers
A ZIP archive's central index is compared field by field against each entry's own local header. Several archive-based signature-bypass tricks rely on exactly this kind of disagreement going unchecked.
Anomalies
Every heuristic finding this analysis produced, gathered in one place - path traversal, compression-bomb ratios, duplicate names, disguised file types and more.
Nested Archives
Archives found inside this archive, opened and analysed in turn, bounded by a depth limit and a shared byte budget. A compression-bomb check runs on each one, using only its declared sizes, before this tool ever decompresses a byte of it.
Extract & Hand Off
Save any readable entry to your device, or open it directly in the forensics tool that matches its own detected type. Nothing here is uploaded anywhere.
Text in Names & Comments
Readable text pulled from every entry name and comment field this tool can see without decompressing anything.
--
File Identification
What the file's own magic bytes say it is, checked against its stated extension.
Carved Files
Every place in the file where another format's signature appears, at any offset - a file appended after another's end is a common way to hide data.
Byte Entropy
Regions of the file that read as close to random, which usually means compressed, encrypted or packed data.
ZIP Integrity
Cross-checks every entry's local file header against the central directory - a mismatch is a sign the archive was hand-edited after the fact.
Hex Viewer & Diff
Every byte of the loaded file. Add a second file to compare them byte-by-byte, with differences highlighted in both.
--
Strings
Every run of readable text in the file, ASCII and UTF-16 alike, with filters for the shapes that matter most in a binary - URLs, paths, IP addresses, registry keys and email addresses.
Understanding Binary & Archive Forensics
Why File Extensions Can Lie
A file's extension is just a naming convention the operating system trusts by default - nothing stops a ZIP archive from being renamed to end in .jpg, or a script from masquerading as a document. Every real file format instead begins with a short, fixed byte sequence (a "magic number") that identifies it regardless of what it is named. Checking those bytes directly, rather than trusting the extension, is the same first step forensic tools and malware sandboxes take before doing anything else with an unknown file - and it is what decides here whether the archive analysis runs at all.
What Entropy Actually Measures
Shannon entropy measures how unpredictable a stretch of bytes is - plain text and simple structured data have low entropy because certain byte values repeat far more often than others, while compressed, encrypted or packed data looks close to random, with every byte value roughly equally likely. A file that is mostly low-entropy but has one high-entropy stretch spliced in is a classic signature of an encrypted payload, packed executable, or compressed archive hidden inside an otherwise ordinary file. Bytes appended after a format's own end marker are invisible to a normal viewer and are what carving at every offset surfaces.
Zip-Slip: A Path, Not a Payload
An archive entry can be named almost anything, including ../../etc/cron.d/evil. A naive extractor that joins the entry name onto the destination folder without checking it first will happily write that file wherever the ../ segments point it - completely outside the folder the user thought they were extracting into. This is not a bug in any one format; it is a bug in trusting a name. This tool checks every entry's name for exactly that pattern, along with absolute paths and Windows drive letters, before any extraction happens.
A Bomb You Never Detonate
A compression bomb is a small file that expands to an enormous one - a few kilobytes on disk claiming gigabytes of content once decompressed. The only safe way to detect one is to read the DECLARED sizes an archive's own header already carries and compare them, never to decompress first and see what happens. This tool computes every ratio from header fields alone; a suspected bomb is reported and left alone, not decompressed "just to check."
Two Headers, One File, Two Answers
A ZIP file has two independent indexes for the same entries: the central directory at the end of the file, and each entry's own local header just before its data. Normal zip tools keep them in sync automatically; almost none check whether they agree. When a name, size, checksum or method differs between the two, different unzip programs can extract completely different content from the same bytes - which is exactly how a signature scanner gets shown one file while the actual extraction produces another, and a strong sign the archive was hand-edited with a low-level tool after it was created.
Archives All the Way Down
A malicious payload is very often not the archive itself but an archive stored inside it - a ZIP inside a ZIP, or a TAR inside a GZIP wrapper (a plain .tar.gz, the same shape a compression bomb loves to hide in). This tool opens what it finds inside an archive and analyses it in turn, bounded by a depth limit and a shared memory budget, running the exact same bomb check at every level before deciding whether it is safe to go one level deeper.
Structure, Not Content
This tool reads bytes and container structure - signatures, entropy, headers, indexes, names, sizes, flags and timestamps - and never decompresses a suspected bomb or a format it cannot safely decode. 7z and RAR entries are listed from their own headers only; neither format's compression is implemented here, by design. A file with no findings is not a guarantee of safety - it means these particular heuristics found nothing to flag, not that the decompressed content itself has been examined. Treat every finding as a lead, and where the stakes are high, extract and inspect the content with tools built for that purpose in an environment you control.
Key Takeaways
- Any file is identified by its bytes, not its name: the magic-byte check, carving, entropy, hex view and strings run on everything you drop; archives additionally get their structure read.
- Compression ratios are computed from declared sizes only: a suspected bomb is reported, never decompressed to confirm.
- Every name is checked for zip-slip, absolute paths and drive letters before this tool - or you - ever extracts anything.
- The central directory is cross-checked against every local header, and archives inside archives are opened too, bounded by a depth limit and a shared byte budget.
- Nothing leaves your device: every parse, check, comparison and (bounded) decompression runs client-side in your browser.