Binary File Inspector

Drop a program file — a Windows PE (.exe, .dll), a Linux ELF binary, or a macOS/iOS Mach-O — and read what it declares about itself before any heavier tooling comes out: its headers, sections and segments, the libraries and functions it imports, its exports and symbols, and every printable string inside it, with MD5 and SHA hashes and per-section entropy alongside. The file never leaves your device and is never executed: it is opened and read in this page, not uploaded, because a binary you are suspicious of is exactly the file you should not be handing to a stranger’s server.

Last updated:

Or drop the file anywhere in this box. Everything below is read from the file itself, on this device. Static analysis only: the file is parsed, never run. Limit: 128 MB.

What this page is — and is not

This is a first-look, static inspection: the file is parsed, never executed, and nothing here is a malware verdict. The findings are observations, not convictions — an unsigned file is a fact (many legitimate tools are unsigned), entropy above 7.2 is a fact (packers raise it, but so do ordinary compressed resources), and an Authenticode signature block being present says nothing about whether the signature is valid, only that one is there. For a second opinion on a file you distrust, compare its SHA-256 against a public verdict with the lookup in the Overview tab — the hash is searched, the file itself is never sent. Android packages have their own dedicated reader, the APK Analyzer; what a program does on the network belongs to the PCAP Analyzer; and the companion article, can AI agents reverse-engineer your app?, explains how far automated analysis now goes.

What a program file declares before it runs

Every native program file opens with a statement of intent written for the operating system’s loader. A Windows PE names its target machine, its build timestamp, the address it wants to be loaded at and the subsystem it expects; its section table lays out where the code, the data and the resources live, and its import table lists — by name — every library and function it intends to call, which is the closest thing a closed binary has to a table of contents. An ELF binary declares its class, endianness and machine, the interpreter that will launch it, the segments the kernel must map and the shared libraries it needs, in order. A Mach-O declares its CPU and file type, its segments and sections, the dylibs it links, a UUID that identifies the build, and whether its code is signed or FairPlay-encrypted. None of this requires running the file, trusting the file, or uploading the file — it is all sitting in headers the loader itself will read.

This page reads exactly that layer, and it is deliberately only the first layer. It will not decompile anything, unpack anything or tell you what the code does — that is the work of Ghidra, IDA and the agent-driven toolchains the companion article walks through. What a first look is for is triage: is this the architecture you expected, is it signed, is it a .NET assembly wearing a native costume, does one section carry suspiciously dense data, does the import list name libraries the program has no business calling, and is the file you were sent the same file everyone else got — which the hashes answer outright (and the hash generator cross-checks for text or smaller files). Five minutes of headers, read locally, answers most of those before any heavy tool is even installed.

Frequently asked questions

Is my file uploaded anywhere?

No. The file is opened and parsed in this page, on your device, and nothing is uploaded, transmitted or stored — analysing a file makes no network request. The only external link on the page is the VirusTotal lookup, and it searches for the file’s SHA-256 hash as text; the file itself is never sent. The page also works offline once it has loaded.

Can this tell me whether a file is malware?

No, and any header reader that promises that is overselling. This page reports what the file declares — format, architecture, sections, imports, exports, strings, signature presence — which is enough to catch the careless cases: the “invoice” that is really a 32-bit executable, the build with one impossibly dense section, the unsigned updater whose hash matches nothing the vendor published. Judging what the code actually does needs decompilation, sandboxing or a reputable scanner’s verdict. Treat a clean-looking result here as “nothing in the headers looks wrong”, never as a safety certificate.

What is entropy, and why is 7.2 the flag?

Shannon entropy measures how random a stretch of bytes looks, from 0 (all the same byte) to 8 (indistinguishable from random). Ordinary compiled code and text sit well below 7; compressed data sits near 8, and encrypted data is effectively 8. Packers compress or encrypt a program’s real code, so a section above roughly 7.2 is a standard triage flag for “something in here was squeezed” — but installers, compressed resources, embedded media and modern runtimes also produce high-entropy sections on entirely legitimate files. It is a reason to look closer, not a conclusion.

Why does my file show so little structure?

Because the page reports what the file actually declares, and some files declare very little. A stripped ELF may have no section header table at all (segments only); a hand-crafted or truncated file may end before the structures its header promises — in which case the notes say exactly that and everything shown was still read from the bytes that are present. And some formats are simply out of scope for the deep parsers: they are identified by name (ZIP, PDF, images and so on) and get the generic facts — size, hashes, entropy, strings — without invented detail.