Why File Extensions Lie

A PNG always starts with the same eight bytes: 89 50 4E 47 0D 0A 1A 0A. A JPG always starts FF D8 FF. FileFlip reads the first 16 bytes of a file the moment you drop it in, and decides what the file actually is before it ever looks at the name you gave it. Rename a WebP to .jpg and none of those bytes move, so every decoder that checks them, ours included, still sees a WebP.

Does renaming a file change what it actually is?

No. Renaming edits characters in the filename and touches nothing inside the file.

• Renaming photo.webp to photo.jpg changes three characters after the dot. The pixel data, still compressed with WebP's VP8 codec, doesn't move. Convert WebP to JPG instead, and FileFlip decodes the WebP and writes real JPEG bytes.
• Renaming photo.heic to photo.jpg is the same story with HEVC-compressed pixels standing in for VP8. Convert HEIC to JPG actually decodes and re-encodes them.
• Your OS, your browser, and FileFlip all check the bytes before trusting the name, which is why a renamed file usually breaks somewhere instead of quietly working.

Magic bytes, and what they look like

Every format that isn't plain text opens with a fixed run of bytes, often called a signature or magic bytes, written by whatever program encoded the file. A decoder reads that run before it does anything else.

The PNG specification defines that exact eight-byte sequence. WebP's RIFF container spec requires the file to open with a RIFF header carrying the WEBP FourCC. HEIC inherits the ftyp box from ISO's base media format, and the four bytes right after ftyp, heic here, name which brand of the format it is; the HEIF technical overview lists the full set of brand codes. None of this depends on a filename anywhere.

How this breaks uploads

A form, an app, or an OS that trusts the extension routes the file wrong before anything reads a single byte. Windows picks the program to open a double-clicked file by extension alone, so a WebP renamed to .jpg opens in your JPG viewer, which then either refuses it or shows a broken image, because the bytes it's holding aren't JPEG. An upload form that only checks the extension will accept the file and hand it to a decoder that can't read it. The failure shows up one step downstream of where the actual mistake was made, which is what makes it confusing to debug.

What actually happens when you feed FileFlip a mislabelled file?

It depends on whether FileFlip's sniffer recognizes the real bytes. We tested both cases directly, on the same converter you'd use.

We built a real WebP with ImageMagick, renamed the copy fake-webp-as.jpg, and dropped it onto the live JPG to PNG converter. The row's format badge read WEBP, not JPG, next to the .jpg filename, and the conversion ran as a WebP-to-PNG job: 71.9 KB in, 561 KB out. The extension never entered into it.

Then we renamed a plain text file to test.jpg and dropped that in instead. Its bytes don't match any signature FileFlip knows, so the sniffer gives up and the extension gets the benefit of the doubt: FileFlip treats it as a JPG and hands it to the decoder. The decoder can't parse it either, and the job fails with "The selected file could not be read as JPG. It may be damaged, or protected with a password." The file isn't damaged. It's a text file that was never a JPG, and the honest error would say so, but the extension is the only reason the app thought JPG in the first place.

Why doesn't renaming actually convert the file?

Because a conversion has to run a decoder and then an encoder, and renaming runs neither. Reading a WebP file means decoding VP8's DCT blocks back into raw pixels; writing a JPG means re-encoding those same pixels through JPEG's own DCT and quantization tables. Skip both steps and you have the original compressed stream sitting behind a new label, which is exactly what a rename produces. The only way to get real JPEG bytes out of a WebP file is to actually run the codecs, which is what a converter does and a file manager's rename command does not.

How do I find out what a file actually is?

Three ways, in order of how much you trust the answer to matter.

Drop it into any FileFlip converter for a format you suspect it might be. If the sniffer recognizes the bytes, the row's badge names the real format before anything converts, which is the same check that ran in the test above. On a Mac or Linux machine, the file command reads the same kind of signature from the terminal: file photo.jpg prints RIFF (little-endian) data, Web/P image if the bytes are really WebP. On Windows, PowerShell's Format-Hex photo.jpg -Count 16 prints the raw bytes so you can compare them against the table above yourself.

Can extensions be wrong without anyone renaming anything?

Yes, more often than an actual rename. Some apps write a file with the wrong extension by design or by bug rather than a person changing it. A messaging app or cloud sync tool that mishandles a HEIC photo, the same file format behind why HEIC won't open on Windows, can save it with a .jpg name while leaving the HEVC-compressed pixels untouched, because the app is guessing at compatibility rather than converting. A download manager or email client occasionally renames an attachment to match its declared MIME type instead of its content when the two disagree. In every one of these cases the fix is the same as for a manual rename: check the bytes, then convert if the format actually needs to change.

What can get past the byte check?

Not every format has a signature FileFlip can check. Formats built on ZIP, such as DOCX or EPUB, and the wider ISO base media family that HEIC and AVIF belong to, share their container structure with other formats, so a generic match there would say nothing useful and FileFlip doesn't attempt one; it only signs off on brands like heic and avif that name themselves inside that container. A .docx file that's secretly something else entirely rides on its extension the same way the unreadable text file did in the test above. Sniffing narrows the problem a long way. It doesn't remove it.

Convert between them

FileFlip converts WebP to JPG and HEIC to JPG entirely in your browser, on WebAssembly builds of ImageMagick. The file is never uploaded, there's no account, and nothing is queued on a server. Drop it in, and if the name and the bytes disagree, the row tells you which one won before you download anything.

Common questions

Is a .jpeg file different from a .jpg file?

No. .jpg, .jpeg, .jpe, and .jfif all name identical JPEG bytes; the four-letter spelling only exists because old Windows filesystems couldn't handle three-letter extensions longer than .jpg. FileFlip treats them as the same format rather than flagging a mismatch when one is renamed to another.

Does Windows check a file's bytes before opening it?

No, Explorer picks which program to launch by extension alone. The program it launches is the one that then reads the bytes, which is why a mislabelled file often opens the wrong app instead of failing immediately, and why the actual error only shows up once that app tries to parse content that doesn't match what it expected.

If FileFlip says my file is really a WebP, do I need to convert it?

Only if you need JPEG bytes for a real reason, like a tool that rejects WebP outright. If you just want the name to match the content, rename it back to .webp; nothing inside the file needs to change, because the bytes were never wrong to begin with. See WebP vs JPG for when each format is actually the right one to convert to.

Can a wrong extension corrupt the file?

No, renaming a file changes an entry in the filesystem's directory listing and nothing else. The bytes on disk are identical before and after. What looks like corruption is usually a program refusing to parse bytes that don't match its expectations, which is a decoding failure, not damage to the file.

How we measured this

• We generated test.webp and test.heic from a Kodak True Color source image with ImageMagick 7.1.2, then copied each and renamed the copy to .jpg.
• We inspected the first bytes of every file with xxd, confirming the values in the magic-bytes table above against the actual bytes ImageMagick wrote.
• We dropped fake-webp-as.jpg and a plain-text file renamed fake-text-as.jpg onto FileFlip's live /convert-jpg-to-png page and recorded what the UI showed: the detected-format badge, the resulting file size, and the exact error text on failure.
• The sniffing logic quoted here is FileFlip's own, in files.ts under the converter's upload handling. It checks a signature against the first 16 bytes of the file and only overrides the extension when a signature matches; an unrecognized signature falls back to trusting the name, which is the behavior the second test shows.

To reproduce the first result yourself: rename any WebP file to .jpg and drop it on any FileFlip image converter. The row's badge will read WEBP.