Also available in: Español · Português · Français · العربية
File signatures
The magic numbers for 33 formats, each with the document that actually defines it — and a file-drop that reads only the head, in your browser.
What is a file signature?
A file signature, or magic number, is a short fixed sequence of bytes at the start of a file that says what kind of file it is. Every PNG begins with the same eight bytes; every gzip archive begins with the same two. Programs read them because the file name is not evidence — renaming a spreadsheet to .png changes nothing about what is inside it, and a file arriving from the internet has whatever name the sender chose.
The list below has 33 formats with their bytes, where in the file those bytes sit, and the media type where one is registered. What it also has, and what tables copied from one another leave out, is the document that defines each signature. That column turns out to be the interesting one.
Because the answer is not uniform. Some signatures are fixed in the normative text of a published standard. Some are only in a vendor's own documentation. Some are in a document that no longer carries any weight. And a few — ICO, bzip2, 7-Zip — are implemented identically by every tool on earth and were never written down as a requirement anywhere.
How to use it
- Drop a file in, or choose one. Only the head of the file is read, and it is read by your browser. Nothing is uploaded. If a signature matches you get the format, the bytes that matched, and where they are defined.
- Or paste the bytes you already have. If you are looking at a hex dump, paste the first few bytes instead. Spaces, 0x prefixes and lowercase are all accepted; the tool just needs an even number of hex digits.
- Search the list by anything on the row. A format name, an extension, a media type, a hex prefix or the name of a specification all work. Typing png puts PNG first rather than burying it under everything that happens to contain those letters.
The PNG signature, and the explanation the standard dropped
PNG is the format worth looking at closely, because its eight bytes are the most carefully designed in the list and the story of them is not what you would expect. They are 137, 80, 78, 71, 13, 10, 26, 10 — or in text, a byte with the high bit set, then PNG, then a carriage return, a line feed, a control-Z and a final line feed.
Every one of those is doing a job. The first byte is deliberately not an ASCII character, so a text file is unlikely to be mistaken for a PNG — and, more usefully, so that a file transfer which strips the high bit from every byte is caught immediately. The carriage return and line feed catch the opposite problem: a transfer that helpfully converts line endings between platforms will mangle that pair, and the file fails at byte five instead of somewhere deep inside the image. The control-Z stops MS-DOS dumping the rest of a binary file to the terminal when someone types it. The final line feed catches the inverse of the CR-LF translation.
Here is the part that surprised us. That explanation is not in the current standard. ISO/IEC 15948, which is what standardises PNG today, states the eight bytes and moves on, keeping a single sentence in its rationale clause to the effect that the signature detects common transmission errors. The byte-by-byte reasoning survives only in RFC 2083 from 1997 — a document marked Informational, which the standard has since replaced. The bytes are normative. The reasons they are those bytes are not.
Honest limits
A signature says what a file claims to be, and that is the whole reason to check it — but it is also the limit. Bytes at the front of a file are cheap to fake. If you are deciding whether something is safe to open, a matching signature tells you the file is well-formed enough to have a plausible header and nothing more.
Not every signature starts at the beginning. The ustar marker that identifies a tar archive sits at byte 257, and ISO 9660's CD001 at byte 32769 — over 32 kilobytes in. Anything that reads only the first four bytes will miss both of the commonest archive and disc-image formats entirely, which is why this tool reads further.
Several formats are indistinguishable at the head, and the tool says so rather than guessing. WebP, WAV and AVI all begin with the same four bytes, because all three are RIFF containers and the bytes that separate them come later. A .docx, .xlsx, .jar, .apk and .epub are all ZIP archives and carry the ZIP signature; telling them apart means decompressing the archive and looking at what is inside, which is a different job. In both cases the tool reports every match rather than picking one.
Plenty of formats have no signature at all. CSV, plain text, most source code and SVG are just characters, and there is nothing fixed at the front to match — SVG in particular is XML, which may or may not start with a declaration. A file that matches nothing here has told you very little.
Finally, 33 formats is a selection rather than a census, and the list is bounded on purpose. The de-facto complete answer is the magic database that ships with the Unix file command, which runs to thousands of rules with conditional logic and byte arithmetic. What is on this page is the subset whose bytes could be checked against a real file this page's tests actually build, so every row here is verified rather than transcribed.
Why is it free?
Because it costs nothing to run. The list is part of the page and the identification happens in your browser: when you drop a file, only its first bytes are read, and they are read locally. Nothing is uploaded, no server sees your file, and there is no account.
The table is not copied from another table. Every row that could be built is checked against a file produced by a real encoder, and cross-checked against the file command's own identification, so a transposed digit fails the build instead of reaching the page. Where a format could not be built here, the page says so rather than quietly leaving it unverified.