Image Format Checker

The Image Format Checker identifies what an image file actually is by reading its binary signature - the magic bytes at the start of the data - instead of trusting the file name. Feed it almost any image and it returns three things: the detected format, the MIME type that matches that format, and whether the file extension agrees with what the bytes reveal.

File extensions are labels, and labels are easy to lie about. Renaming photo.jpg to photo.png changes nothing inside the file; the content remains a JPEG while every program that reads the extension now expects PNG. The mismatch confuses operating systems, browsers, CDN rules and image tooling, and resolving it by inspection is exactly the scenario this checker exists for.

The detection itself is fast because it does not decode the image. The checker reads a small leading window of bytes - typically under 32 - and compares them against a table of known signatures. JPEG starts with FF D8 FF, PNG with 89 50 4E 47, GIF with 47 49 46 38, and BMP with 42 4D; WebP, AVIF, TIFF and ICO follow their own patterns. The comparison takes microseconds.

The result is a verdict, not a guess. When the extension matches the signature, the checker reports a clean agreement. When the file was renamed or mislabeled, it shows the mismatch and the true format, so you can correct the extension before serving the file anywhere that cares.

Use it when an upload silently fails, when a downloaded asset opens in the wrong application, when a CDN serves a file with an unexpected Content-Type, or when you inherit a folder of mystery files and want the truth in one pass. It pairs naturally with the MIME Type Checker when you need the raw MIME string and with the Content-Type Checker when your goal is the exact HTTP header for a server rule.

Everything runs locally in your browser. Only the leading bytes are read and nothing is uploaded, so files up to the practical 25 MB ceiling are safe to inspect even when sensitive, and the original is never modified. If no signature matches, the file is reported as unknown - which usually means corrupt, truncated, or a format outside the recognized set.

Nearly every file format declares its identity in the first bytes of its data. These are called magic bytes or file signatures, and they exist so that parsers - browsers, image libraries, operating systems - can recognize a format without being told what it is. The sequence is often a deliberate brand marker or a product of the format's design history, and it is stable across every file of that type.

For the checker this stability is the whole foundation. Read the leading window, compare it to a known table, and the format resolves itself with no dependence on the file name, the download source, or the folder the file arrived from. The extension is only a convenience label; the signature is ground truth.

• JPEG begins FF D8 FF - a binary opener shared by every JPEG ever written.
• PNG embeds its own name: 89 50 4E 47 spells the format in its first meaningful bytes.
• GIF writes the letters GIF plus a version marker such as 89a.
• BMP opens with 42 4D, the ASCII characters for Bitmap.
• WebP is a RIFF container, so it starts with RIFF and carries WEBP a few bytes later.
• AVIF is an ISO base media file, announced by an ftyp box near offset 4.

Every supported type is listed with the byte pattern used for detection and the MIME type that the detected format maps to. Keeping both in one place means the extension comparison has an authoritative reference: the checker decides the format from bytes before it ever compares a name.

Recognized formats span the everyday raster set plus the vector and container cases - JPG, PNG, GIF, BMP, WebP, AVIF, TIFF, ICO and SVG. If a file belongs to one of these families, its signature will resolve to exactly one row in the table.

The comparison step matters because real files really do get mislabeled. Files arrive from scrapers with forced extensions, from scripts that renamed thumbnails, and from email clients that sanitized names. Each case produces a file whose extension and content disagree, and each disagreement can break a downstream system in a characteristic way.

None of the failure modes below are detected by opening the file in a viewer - a viewer that trusts the extension may refuse or misinterpret. That is why signature verification belongs in the workflow rather than in the double-click.

Three supported types deviate from the tidy binary-template story, and knowing their quirks prevents confused readouts. SVG is XML text, not binary; it is detected by the XML or SVG tag in the opening text rather than by magic bytes. Heavily minified SVGs can push the identifying tag slightly deeper, which the checker handles by reading a generous leading window.

TIFF declares its byte order in its first two bytes - II for little-endian or MM for big-endian - followed by the pair 2A 00 or 00 2A. ICO files are containers that frequently wrap PNG data, so an ICO can also appear to contain PNG; the checker recognizes the container header first and reports the container, which is the identity most pipelines care about.

• SVG reports as image/svg+xml with a text-based detection path.
• TIFF detection respects both endian variants of its header.
• ICO wrapping PNG is normal; the container is the reported identity.
• Minified SVG markup stays detectable as long as the tag falls inside the read window.

Signature detection is excellent at identifying format, but it is deliberately silent about everything else. It cannot tell you whether a JPEG is double-compressed or full of artifacts, whether a PNG is palette-based or photographic, whether an image still has its metadata, or whether a file is genuinely complete rather than truncated mid-way. A file can carry a perfect signature and still be broken afterwards.

The checker is honest about this boundary: its job is identity, not health. When a signature matches but the file still will not open, the failure is downstream of the header - corruption deeper in the data, a download interrupted partway, or an encoder that produced a non-conforming payload.

• Identity: guaranteed within the supported signature table.
• Integrity: not assessed - a valid header does not prove a valid body.
• Origin: not assessed - screenshots, edits and camera exports share signatures.
• Codec: not assessed - a modern JPEG can still open with the classic FF D8 FF opener.

When the checker flags a mismatch, resist the urge to brute-force rename. Renaming a PNG file to .jpg changes the label and keeps the bytes, so any pipeline that sniffs or enforces file types will still misbehave. The correct fix is to re-encode the file into the format its name claims, producing a file whose extension and signature genuinely agree.

If you simply want the name to reflect reality, rename the file to match the detected format - a PNG mislabeled as .jpg becomes file.png and the agreement is instantly correct. Choose whichever direction your destination demands, then re-run the checker to confirm the file now reports clean.

• Rename to the detected format when the name is the lie.
• Re-encode when the destination insists on a particular extension.
• Re-download when a file is corrupt beyond the header.
• Re-check after every change to confirm the verdict flipped to a match.