How this data is compiled and checked

Source precedence, verification, exclusions, and how to tell us we got it wrong.

This site publishes technical claims: that a .heic file starts with a specific run of bytes, that a format declares a specific MIME type, that a given free program opens it. A claim like that is worth nothing unless you can check it. This page says exactly where each kind of fact comes from and what we refuse to publish.

Source precedence

When two sources disagree, the higher one on this list wins. That order is fixed and it is the reason a handful of widely copied signature values do not appear here.

  1. The format specification itself. The ISO, IETF, W3C or vendor document that defines the format. For a header that means the actual byte layout section, not a summary of it.
  2. The IANA media types registry. The authority for whether a MIME type is registered, and for the difference between a registered type and a vendor or experimental one carrying a vnd. or x- prefix.
  3. Vendor and reference-implementation documentation. Apple, Adobe, Microsoft and the reference libraries (libheif, FFmpeg, libpng and their peers), used for behaviour a specification does not pin down.
  4. Cross-check references.Wikipedia's List of file signatures and the GCK file signature table hosted by SEARCH. These are used to catch a mistake, never as the sole source for a value.

What is never a source: another file-extension website. Copying between reference sites is how a wrong offset survives for twenty years.

How a signature is verified

A signature enters the catalogue with its hex bytes, the offset those bytes sit at, and what they read as in ASCII where that is meaningful. Three checks run before it is published, two of them automatically on every build:

Currently 111 distinct signatures are catalogued, deduplicated across the formats that share them, checked against 33 named references.

What is deliberately left out

Per-record citations

267 of the 289 format records carry their own list of references, shown in a Sources section at the foot of the page. That coverage is being extended; a record without citations is one whose sources have not been written up yet, not one that was made up.

Corrections

If something here is wrong, it should be fixed rather than argued about. Send the format, the claim, and the source that contradicts it through the contact page. Corrections are made in the dataset itself, so the page, the API record and the sitemap date all move together.

Who publishes this

WhatFileType is built and maintained by FusionStudios, the Netherlands. It is a small, independent reference project: no accounts, no tracking cookies, and no file ever leaves your browser.

Frequently asked questions

Where does the signature data come from?

Primarily from the format specifications themselves, plus the IANA media types registry for MIME types. Two secondary references are used to cross-check rather than to source: Wikipedia's List of file signatures and the GCK file signature table now hosted by SEARCH. Every signature page lists the specific references it was checked against.

Why do some formats have no signature listed?

Because they genuinely have none. Plain-text formats such as CSV, JSON, YAML and source code have no fixed header, and neither do a number of headerless binary formats. Those records deliberately carry an empty signature list and their pages say so, rather than showing a table with a placeholder row in it.

How is an error corrected?

Report it through the contact page with the format and the source that contradicts what is published. Data corrections are made in the dataset, which means the page, the API record and the sitemap's lastmod all move together. There is no separate copy of the data to fall out of step.

Can I reuse this data?

Yes, under CC BY 4.0, through the free JSON API. No key, no rate limit, no sign-up. Attribute it to WhatFileType with a link and you are done.

The references we cite most