Why Can a File Named .jpg Actually Be a PNG?

Take a PNG image called photo.png and rename it photo.jpg. The name changes, but the image data does not.

It still uses PNG's file structure and compression. Any transparency is still there. The pixels have not been re-encoded as JPEG. You now have a PNG file carrying a .jpg filename.

That mismatch explains why the file may behave differently from one program to another. An image viewer might open it normally, an upload form might reject it, and another application might identify it correctly as PNG.

The reason is simple: software does not have to rely on the filename alone when deciding what kind of file it is looking at.

The .jpg or .png at the end of a filename is called the file extension. It is a useful label that tells people and software what the file is expected to contain.

Extensions also help operating systems decide which application should open a file. A .jpg file will usually be sent to an image viewer, while a .pdf may open in a browser or document reader.

The important distinction is that the extension belongs to the filename. It is not the encoded file format itself.

Renaming photo.png to photo.jpg is similar to changing the label on a container. The description on the outside has changed, while the contents remain exactly as they were.

Many file formats begin with recognizable byte sequences that software can use as evidence of what the file contains. These patterns are commonly called file signatures or magic numbers.

The PNG specification defines an eight-byte signature at the beginning of every PNG file. Several of those bytes correspond to the letters P, N and G.

JPEG data begins differently. A JPEG stream starts with the marker bytes FF D8 and is structured according to the JPEG format rather than the PNG specification.

Software can therefore inspect the beginning of a file instead of trusting the extension. If the filename ends in .jpg but the first bytes match PNG, that disagreement is immediately visible.

Suppose holiday.png is renamed to holiday.jpg. From the filename alone, it now appears to be a JPEG.

The internal data tells a different story. The PNG signature is still present, and the rest of the bytes are still arranged as a PNG image.

A program that depends mainly on extensions may try to treat the file as JPEG. A program that examines the bytes can recognize it as PNG instead.

This is why two applications can appear to disagree about the same file. They may simply be using different evidence to identify it.

Changing an extension does not convert one image format into another.

A real PNG to JPEG conversion requires software to decode the PNG image and then encode the pixels again using JPEG's format and compression rules.

That process can change the image. PNG supports transparency, while ordinary JPEG does not. PNG normally uses lossless compression, while JPEG is typically lossy. The formats also organize image data differently inside the file.

A converter therefore creates a new representation of the image. A Rename command only changes the filename.

Many image applications are designed to recover gracefully from a misleading extension.

Instead of assuming that .jpg guarantees JPEG data, an image viewer may inspect the file, recognize a valid PNG structure, and pass it to a PNG decoder.

From the user's point of view, photo.jpg appears to work perfectly. That can make it look as if changing the extension converted the image.

What actually happened is that the software recognized the real format despite the incorrect filename.

Websites also need to decide what kind of file a user has uploaded, and different services use different checks.

A simple upload form may look at the filename extension. Another system may consider the media type reported by the browser. A stricter service may inspect the file signature or attempt to decode the uploaded image before accepting it.

Those pieces of information can disagree. A PNG renamed to .jpg may arrive with a JPEG-looking filename while still containing PNG data.

The website may then reject the file when a later validation step discovers that the reported type and the actual contents do not match.

Imagine two websites that both accept JPEG and PNG images. One may simply try to decode the upload as an image. If the PNG data is valid, the incorrect extension might not matter.

Another website may require the filename, reported media type and detected format to agree. The same image can fail there even though nothing is wrong with its pixels.

A service might also choose a decoder based on the extension. If it sends a file named .jpg to a JPEG decoder and the data is actually PNG, decoding can fail.

This is one reason an image may open normally on your computer but produce an "invalid file type" or "unsupported image" message when uploaded elsewhere. The file may be perfectly valid while its name describes the wrong format.

A filename is user-controlled information. Anyone can rename a file, either accidentally or deliberately, so upload systems have good reasons to verify more than the extension.

OWASP recommends using several checks when validating uploads. Depending on the application, those checks can include an allowlist of extensions, validation of the reported content type, inspection of file signatures and actual processing of the file with an appropriate parser or image library.

No single check is enough for every situation. An extension can be wrong, a reported media type can be misleading, and a short signature check does not prove that the entire file is valid.

For an ordinary user, all of this security work may be hidden behind a vague upload error. The server is often doing something sensible: verifying that the file really is what its name claims.

Files transferred on the web are also described with media types, commonly called MIME types. JPEG normally uses image/jpeg, while PNG uses image/png.

When a server sends an image to a browser, it can identify that data through the HTTP Content-Type header. Uploads can also carry type information supplied by the browser.

A media type is still metadata describing the file. It is not a replacement for the actual encoded bytes.

The reported type can be wrong, just as the extension can be wrong. MDN specifically warns that the type value associated with a local Blob or File should not be treated as a reliable way to determine the real file type because it can depend on extension or operating-system information.

File identification therefore often involves several layers: the filename, the reported media type, the file signature and the validity of the full file structure.

The term "magic number" can make format detection sound easier than it really is. Recognizing a few bytes at the beginning of a file is useful, but robust validation may need to examine much more.

Not every format has one simple unique signature. Some formats act as containers for several kinds of data. Files can also be truncated, malformed or deliberately constructed to confuse weak detection logic.

This is why security guidance recommends combining file-signature checks with other validation rather than treating the signature as absolute proof.

For an everyday image with the wrong extension, however, the basic lesson remains useful. The bytes inside the file can reveal information that the filename does not.

Removing .png from the end of a filename does not erase the PNG image stored inside it.

The extension makes the format convenient for people and software to recognize, but the underlying encoded data remains unchanged.

It helps to separate three things that normally agree with one another: the filename, metadata describing the type, and the actual bytes in the file.

A normal JPEG might be called photo.jpg, reported as image/jpeg, and contain valid JPEG data. Because those three clues usually agree, there is little reason to think about the distinction.

The difference becomes obvious only when one of them stops matching the others.

If an image has a suspicious extension, simply renaming it again is not the best way to identify its real format.

Image editors and metadata tools can often report the detected format after opening the file. More technical tools can inspect its signature directly. A PNG begins with its defined eight-byte signature, while JPEG has its own marker structure.

Another practical test is to open the image in software that can export or save to a specific format. If the file needs to become JPEG, exporting it as JPEG creates properly encoded JPEG data rather than relying on the existing filename.

This is especially useful when an upload repeatedly fails despite the extension appearing correct. The extension may have been changed at some point without the image itself ever being converted.

If a website requires JPEG and your image is PNG, WebP, AVIF or another format, changing the letters after the dot is not a reliable solution.

Convert the image instead. A proper converter reads the source format and writes a new file encoded according to the destination format. The .jpg extension then accurately describes the contents.

The same principle applies well beyond images. Renaming a PDF to .docx does not create a Word document. Changing the extension of a ZIP archive does not rebuild it in another archive format. Renaming a video does not change the codec used to encode it.

A filename tells software what a file is expected to be. The encoded data determines what the file actually contains.