You right-click a photo, save it, and the file that lands in Downloads ends in .webp. Sometimes it is worse: the file ends in .jpg, and the editor you open it in says it is not a valid JPEG. Neither is a fault on your machine. The server decided what to send after reading a line your browser attached to the request, and the name on the file and the bytes inside it no longer have to agree.
The Server Reads Your Browser's Accept Header
Every image request a browser makes carries an Accept header listing the formats it can display. Chrome's, for an image, reads image/avif,image/webp,image/apng,image/*,*/*;q=0.8. Firefox and Safari send their own lists, and every current version includes image/webp.
That header exists for exactly this purpose. HTTP calls it content negotiation, and RFC 9110 describes it as the server choosing the best representation of one resource for the client asking. An image CDN sees image/webp in the list, converts the original JPG or PNG once, caches the result, and serves the WebP to every browser that advertised support. The URL in the page never changes. It can end in .jpg while the response body is WebP, with the real type stated only in the response's Content-Type header.
When you save the image, the browser writes the bytes it received. Most browsers pick the extension from Content-Type, which is why you see .webp. Some keep the extension from the URL, which is how a WebP ends up named .jpg.
Reading the Real Format From the First Bytes
File extensions are labels anyone can change. The format itself is declared in the first few bytes of the file, which every decoder checks before anything else. These signatures are fixed by each format's specification, so they are a reliable way to settle what a file actually is.
You can see them with any hex viewer, or with xxd file | head -1 on macOS and Linux and Format-Hex file | Select-Object -First 1 in PowerShell. A file that starts with RIFF and has WEBP at byte 8 is a WebP whatever its name says, and renaming it will not change what is inside.
Signatures of the Common Web Formats
Bytes shown in hex, with the ASCII reading where there is one. Offsets count from zero.
| Format | First bytes | Defined by |
|---|---|---|
| JPEG | FF D8 FF | ITU-T T.81, the SOI marker |
| PNG | 89 50 4E 47 0D 0A 1A 0A (‰PNG␍␊␚␊) | W3C PNG specification |
| WebP | 52 49 46 46 (RIFF), size, then 57 45 42 50 (WEBP) | RFC 9649, the RIFF header |
| GIF | 47 49 46 38 39 61 (GIF89a) or GIF87a | GIF89a specification |
| AVIF | ftyp at byte 4, then brand avif or avis | AV1 Image File Format, on ISO BMFF |
The PNG signature is designed to catch broken transfers
The eight PNG bytes are not arbitrary. The first is outside the ASCII range, so a system that strips the high bit damages it visibly. The carriage return and line feed pair, followed later by a lone line feed, gets mangled by any tool that converts line endings as if the file were text. The 1A byte stops the old DOS type command from printing binary garbage. A PNG that was transferred in text mode fails at its first eight bytes instead of decoding into nonsense.
PNG or JPG: Which Format to Convert To
Converting a WebP is a choice between keeping it exact and keeping it small.
PNG keeps it exact. PNG is lossless, so the pixels decoded from the WebP are written out as they are, with no second round of compression stacked on the first. Transparency survives, as an alpha channel with the same 8 bits per pixel WebP uses. The cost is size: most WebPs on the web are lossy, and a lossy photograph stored losslessly is typically three to ten times larger, because PNG now has to record the noise lossy compression was free to approximate.
JPG keeps it small. A JPG of a photograph stays close to the WebP's size and opens in almost anything. It cannot hold transparency, and it compresses again, so some quality is lost in the process. For photos at quality 90 that loss is hard to find. For logos, screenshots and text it shows up as faint ripples around edges.
The rule that falls out is short. Screenshots, graphics, anything with transparency, and anything you will edit further go to PNG. Photographs you just need to open, send or print go to JPG.
Turn WebP into a PNG that opens anywhere
Transparency kept, no second round of compression, up to fifty files at once as a ZIP.
Cases Where the Conversion Behaves Differently
Most WebPs convert without surprises. These are the ones that do not.
Animated WebP
An extended WebP can hold a sequence of frames, signalled by the animation flag in its VP8X header. A browser canvas only exposes the first frame, so a converter that goes through one produces a still. PNG's animated variant, APNG, is not something a canvas can write. If the motion matters, convert to GIF or MP4 with a tool built for animation.
Half-transparent pixels
Canvas pixels are stored premultiplied, with each color channel already scaled by its opacity. Writing a PNG divides that back out, and a pixel at 2 or 3 percent opacity has so few levels left that its color can come back a step or two off. The HTML specification itself warns that converting to and from premultiplied values is lossy. It affects only pixels that are nearly invisible.
Wide-gamut images
A WebP can carry an ICC color profile in an ICCP chunk. Browsers convert profiled images into the canvas's sRGB space when they decode them, so an image tagged Display P3 comes out in sRGB, with its most saturated colors pulled slightly inward. Web images are almost always sRGB already, so this rarely shows.
Metadata
EXIF and XMP data in a WebP live in their own chunks and are not part of the pixels, so they do not survive a trip through a canvas. For an image saved from the web that is usually nothing worth keeping.
Do You Need to Convert at All?
Support has spread a long way since Safari, the last major holdout, added WebP in version 14 in 2020. Every current browser displays it. Recent versions of Windows' Photos app, macOS Preview, GIMP and Photoshop open it, and most chat and social apps accept it as an upload.
The gaps that remain are specific and stubborn: upload forms that check the extension against a list of jpg, jpeg and png, older office suites, some print services, email clients that render attachments inline, and any tool that has not been updated in years. Converting is the right move when the file is going to one of those. When it is only going to be viewed, a current viewer will likely open the WebP as it is.
Frequently Asked Questions
Related Tools
Keep Reading
WebP to JPG: What a Second Lossy Pass Actually Costs
VP8 predicts 16×16 macroblocks and JPEG cuts a fixed 8×8 grid, so their artefacts never line up. Where the double compression shows and which quality hides it.
What the JPEG Quality Slider Is Really Doing to Your Photo
Quality 80 scales the quantization tables to 40 percent, it does not keep 80 percent of the picture. Where the setting stops being free, and why PNG has no dial.
How WebP Keeps Transparency Exact in a Lossy Image
Lossy color, lossless alpha, two planes in one RIFF file. What the ALPH chunk stores, when lossless WebP beats PNG, and why Safari cannot write one.