Four Checkpoints Decide What Your File "Actually Is." Only One Can't Be Fooled.

Rename a PNG to photo.jpg and drop it into almost any tool on the internet, and it will work. Not because the tool is being lenient. Because the file extension was never actually the thing being checked, it's the thing everyone assumes is being checked, right up until they test it. Here are the four checkpoints a file passes through between being selected and being processed, ranked from least to most trustworthy.

Checkpoint one: the file extension

What it actually is: Three or four characters after a dot, typed by whoever last saved or renamed the file. Nothing more.

How much it can be trusted: Essentially not at all, and this isn't a flaw, it was never designed to be verified against anything. A file extension is a label, not a lock. Renaming photo.png to photo.jpg through a batch rename tool changes precisely nothing about the bytes inside the file, it changes three characters in the filename and leaves the actual image data, the part that determines what the file is, completely untouched.

What we confirmed: Taking a real PNG, renaming it to .jpg through a bulk rename tool, and uploading it to a converter set to accept JPG files, and it went through without a hitch, correctly, as the PNG it actually was.

Checkpoint two: what your operating system shows you

What it actually is: The icon, thumbnail, and "Type of file" label your file browser displays, which is generally also just reading the extension, sometimes with a quick peek at the content for generating a thumbnail preview.

How much it can be trusted: A little more than the extension alone, since a thumbnail that renders correctly at least confirms something in the file decoded successfully, but the "Type of file: JPG File" label sitting above that thumbnail is still, in most operating systems, extension-driven and just as renamable as the file itself.

Checkpoint three: what the browser's upload filter accepts

What it actually is: When a website's file picker only lets you select "image/jpeg" files, or a converter's interface has you click a "JPG" tab before uploading, that filtering is typically checking two things: the file extension, and a type property the browser reports based on that same extension. Neither one has opened the file to look inside.

How much it can be trusted: About as much as checkpoint one, because it's largely built from the same information. This is exactly the layer a mismatched file sails through, a mislabeled PNG selected under a "JPG" filter passes this checkpoint without complaint, because nothing at this stage has actually looked past the label yet.

Checkpoint four: the decoder, reading the file's actual signature

What it actually is: The moment a file gets handed to the software or browser engine that has to actually turn it into pixels, on this converter, that's the browser's native image decoder or a WebAssembly-based decoder for less common formats, that decoder doesn't care what the filename says. It reads the first few bytes of the file itself, a short binary signature every real image format begins with: FF D8 FF opens a genuine JPEG, 89 50 4E 47 opens a genuine PNG, 52 49 46 46...57 45 42 50 opens a genuine WebP, regardless of what extension is sitting on the end of the filename.

How much it can be trusted: Completely, because this is the one checkpoint that isn't reading a label at all, it's reading the actual structure of the data. This is also why the mislabeled PNG from checkpoint one converted correctly: once it reached this stage, the decoder found real PNG bytes, decoded them as a PNG, and processed the file for what it genuinely was, the incorrect .jpg extension never entered into that decision.

What happens when the mismatch goes the other way

Rename a corrupted file, or a plain text file, to image.jpg and the outcome is different, and revealing. The first three checkpoints won't catch anything wrong, extension, OS label, and upload filter all see a .jpg and wave it through. Checkpoint four is where it actually fails: the decoder looks for a valid image signature at the start of the file, doesn't find one, and returns an error, "corrupted image" or "unsupported file," not because the extension was wrong, but because there was never real image data behind it to decode in the first place.

Why this matters past a mislabeled file

This same four-checkpoint gap is the foundation of a well-documented security concern, one that has nothing to do with ordinary users renaming photos by accident. A system that only validates uploads by checking the file extension or the browser-reported MIME type, without ever inspecting the actual byte signature, can be tricked into accepting a file that isn't remotely an image, a script or executable renamed with an image extension, if the destination system trusts checkpoint one or three as though it were checkpoint four. This is exactly why serious upload validation, on any platform handling files from the public, checks the actual file signature server-side rather than trusting what the client claims the file is.

The practical takeaway

A file extension is a note left by whoever named the file last, not a property of the file itself. If you need to know what a file actually is, not what it's labeled, the only reliable way is to let something read the actual bytes: open it, or run it through a tool that decodes based on content rather than filename. Everything before that point, the icon, the label, the upload filter, is just repeating the same guess back to you with more confidence than it's earned.