File formats

File Signatures And How Software Knows a Format

A wrong extension is a labelling mistake, not damage. The bytes were never touched and renaming costs nothing.

Robert Smith 4 September 2026 7 min read

A file signature is the short run of bytes at the very start of a file. A filename is a claim. The first few bytes are the evidence. Most formats open with a short run of bytes announcing what they are, put there by the program that made the file and untouched by anybody renaming it afterwards. Reading those bytes answers what a file is when the name has stopped being reliable.

Mail is where this gets awkward. That is worth knowing before trusting any tool that identifies files for you. Roughly half the formats mail uses have no signature at all.

What a File Signature Is And Where It Sits

Open almost any binary file in a hex editor and the first line gives the format away. The bytes never vary. Neither does their position. The creating program writes them without being asked.

25 50 44 46        %PDF        a PDF
50 4B 03 04        PK..        a zip. Or anything built on one
D0 CF 11 E0        ....        a compound file, so an MSG or an old .doc
21 42 44 4E        !BDN        a PST or an OST
FF D8 FF           ...         a JPEG
89 50 4E 47        .PNG        a PNG

Some of these are readable and that is deliberate. A PDF opens with the letters PDF and a zip opens with PK, the initials of Phil Katz who wrote the format. Whoever designed these expected somebody to look one day. They made it easy.

Three Ways Software Decides What a File Is

Software has three options and they disagree often enough to matter.

The extension A claim, not a factFast, free and wrong whenever somebody renamed something. Windows leans on this more than anything else does
The signature Evidence, up to a pointReads what the creating program wrote. Renaming cannot touch it. Narrows the answer without always settling it
The whole structure Slow and conclusiveParse the file and see whether it holds together. The only method that catches a faked opening. Also far too slow to run on everything

Most tools use the first two and stop. That is a reasonable trade until a file turns up whose opening bytes were chosen to get past exactly that check.

Browsers had to be talked out of guessing. Early ones inspected content and overrode the declared type when they disagreed, which turned an uploaded image into a script often enough to be a real problem. The header that switches it off, X-Content-Type-Options, exists because content sniffing was a security hole rather than a convenience.

Why the PK File Signature Tells You Little

The zip signature is the clearest example of a signature narrowing a file without naming it.

Opens with PK	What it actually is
archive.zip	A zip, as labelled
report.docx	A zip holding Word XML
figures.xlsx	A zip holding Excel XML
export.olm	A zip holding Outlook for Mac XML
book.epub	A zip holding HTML and a manifest
notes.odt	A zip holding OpenDocument XML

Every row opens identically. To tell them apart something has to go inside and look at what was packed, which means unzipping before the question can be answered.

This is why an OLM is sometimes reported as a zip archive. The tool read four bytes, got a correct answer and stopped. Renaming one to end in .zip and opening it works for the same reason. It is the quickest way to see inside without any special software.

The Formats With No File Signature at All

Here is the part the reference tables skip. A signature only exists where the format defines one. Text based formats mostly do not.

Has a Signature

PST and OST, both !BDN
MSG, the compound file bytes
OLM, the zip bytes
DBX, its own four bytes

Has None

EML, which starts with a header line
MBOX, which starts with the word From
MHT, which starts with headers too
EMLX, which starts with a number

The right column is half the mail formats in common use. None of them can be identified by matching fixed bytes, because there are no fixed bytes to match.

What software does instead is look for a pattern rather than a constant. An EML begins with something shaped like a header, a name then a colon then a value. An MBOX begins with the five characters From followed by a space. Both are guesses that work nearly always and fail on the awkward cases.

EMLX is the hardest of the lot. It opens with a byte count, which is a different number in every file, so there is nothing constant to test. Software either checks for the property list at the end or gives up and trusts the extension. That is why an EMLX so often gets reported as an EML, which is close enough to be believable and wrong enough to cause trouble.

What a Wrong Extension Actually Means

People treat a mismatch as damage. It almost never is.

What you have	What it means	What to do
Name says PDF, bytes say PK	Somebody renamed an Office file	Rename it to match the bytes
Name says DOC, bytes say D0 CF 11 E0	Correct, an old compound file	Nothing, it is what it says
Name says EML, starts with a number	An EMLX with the wrong label	Rename it, then it opens
Bytes match nothing at all	A text format. Or a damaged file	Open it in a text editor and look
Right signature, will not open	Truncated or genuinely damaged	Now repair is the right word

Only the last row is a damaged file. Everything above it is a labelling problem. Renaming costs nothing and risks nothing, since the bytes are never touched.

Renaming does not convert. It changes the label so the right program opens the file. Calling an MSG an EML does not turn it into one. The program that opens it finds compound file bytes where headers should be. The rename only helps where the name was wrong and the bytes were always right.

Reading a File Signature Yourself

Start in a plain text editor. Text formats read as text, so an EML or an MBOX shows its headers straight away. Anything that comes out as noise is binary. The noise itself is useful information.
Use the file command where you have one. Mac and Linux ship it. It reads the signature and reports a format rather than guessing from the name.
Reach for a hex editor on anything binary. The first line is all you need. Compare it against the openings above or against the published list.
Where the answer is PK, look inside. Rename to .zip, open it and read the folder names. Word, Excel, OLM and EPUB are obvious once unpacked.
Treat the extension as the last word, not the first. Everywhere else it is the first thing checked, which is exactly why it is the thing most often wrong.

A hex editor is a reader rather than an editor here. Nothing needs writing to answer this question. Open, read one line, close. Editing bytes by hand is a different job entirely and not one this question calls for.

Where a folder has arrived with names nobody trusts, sorting by what the bytes say rather than what the labels claim is the first useful step. Our file viewers read the contents rather than the extension, so a mislabelled file still opens as what it is. The converters take it from there once you know what you are holding.

Signature values checked against the Wikipedia file signature list and against the format specifications named in each case, in August 2026.

Questions People Ask

7 questions, answered in full below.

What is a file signature?

A fixed run of bytes at the start of a file that names its format. It is written by whatever created the file and it does not change when somebody renames the file, which is why it carries more weight than the extension.

Does renaming a file change what it is?

Not at all. The bytes are untouched and only the label moved. Software that reads the signature will identify it correctly and be confused about why the name disagrees. Software that trusts the name will try to open it as something it is not.

Why do Word and Excel files start the same way?

Because both are zip archives with different contents inside. So are OLM, EPUB, ODT and a good many others. The signature tells you the container and says nothing about what was packed into it.

How do I check a file signature myself?

Open it in a hex editor and read the first line. On Mac and Linux the file command does the same. Both show you the actual opening bytes. A plain text editor works too when the format is text based, because then the signature is readable.

Do all files have one?

No. That is the part most reference tables leave out. Text based formats have nothing fixed at the front, so there is nothing to match. Several mail formats sit in that group, which is why software still falls back on the extension for them.

Can a signature be faked?

Yes. It is a known trick. Putting valid opening bytes on a file gets it past a check that only reads the first few. Anything serious validates the whole structure rather than the first line, which is a slower job and a much harder one to fool.

My file has the wrong extension. Is it damaged?

Almost certainly not. A wrong extension is a labelling mistake and the contents are usually intact. Read the signature, work out what it really is, rename it to match and it will open. Nothing needs repairing.

Sources

Where the figures and behaviour described above were checked.