WebP vs JPG vs PNG: which format should you use?
This is one of those questions with a short answer and a long answer. The short one: photographs go in WebP or JPEG, screenshots and logos go in PNG. The long answer is about the cases where that rule breaks, and those are the cases that waste people's afternoons.
Batch-convert between WebP, PNG and JPEG without uploading. Handles transparency properly when converting to JPEG.
The thirty-second version
| JPEG | WebP | PNG | |
|---|---|---|---|
| Compression | Lossy | Lossy or lossless | Lossless only |
| Transparency | No | Yes | Yes |
| Animation | No | Yes | No |
| Relative size | Baseline | Smallest | Largest for photos |
| Works everywhere | Yes | Almost — see below | Yes |
| Good at | Photographs | Everything, best of both | Text, flat colour, sharp edges |
| Bad at | Text and sharp edges | Nothing much, except old software | Photographs (huge files) |
On paper WebP wins almost every row, which is why it exists. The reason it has not replaced everything is entirely about the last row of the "works everywhere" line, and that is not a technical question — it is a question about what the software at the other end will accept.
Why JPEG fails on text and PNG fails on photographs
Both failures come from the same cause, which is worth understanding because it explains the whole table.
JPEG compresses by throwing away detail it estimates you will not notice. It was designed around photographs, where neighbouring pixels are usually similar and small errors are invisible in a mass of texture. Applied to a screenshot, it produces exactly the wrong result: thin dark lines on a white background have no neighbouring similarity to exploit, so the algorithm's approximations show up as fuzzy halos around every letter. Text that was crisp becomes muddy, and it gets worse each time the file is saved.
PNG is the opposite: it stores every pixel exactly. That is perfect for flat colour, sharp edges and text, where the file only needs to record a few distinct values. It is terrible for a photograph, where every one of millions of pixels is slightly different and all of them have to be written down.
The practical test: is the image mostly a continuous surface, or mostly sharp boundaries? Continuous surfaces — skin, sky, fabric, food — want JPEG or WebP. Sharp boundaries — text, charts, UI, logos — want PNG or WebP.
Where WebP support still fails
Browser support for WebP is effectively universal now, on every current version of every major browser. The failures come from everywhere else:
- Upload forms and application portals. Plenty of back ends were written to accept
image/jpegandimage/pngand have never been updated. A WebP submitted to one of these is rejected, sometimes with a message about file type, sometimes with a message about file size, and occasionally with no message at all. - Email clients and desktop software. Older mail clients, office suites and print layouts may refuse to render it.
- Marketplaces and CMS platforms. Many accept WebP for uploads now, but some convert it on the way in or on the way out, and a few in older niches still do not accept it at all.
- Anything going to print or to a designer. Print workflows expect TIFF or high-quality JPEG. Sending a lossy WebP to a print shop is a way to get a phone call.
- Some messaging apps. Several will happily display a WebP but re-encode it into something else when forwarding, which quietly changes what you sent.
So when should you actually use WebP?
On your own website, almost always. That is where WebP's advantages are fully usable and its one weakness — downstream acceptance — does not apply, because you control both ends. Smaller files mean faster pages, and page speed affects both how long people stay and how search engines rank you.
When you need transparency and a small file. This is WebP's strongest single case. A transparent PNG of a logo or a cut-out product is often several times larger than the WebP equivalent with no visible difference. If you have been distributing transparent PNGs because JPEG cannot do transparency, WebP is the format you were waiting for.
When you are fighting a hard file size limit on a photograph. At equivalent visible quality, WebP is typically 25–35% smaller than JPEG. When a form says 100 KB and your photograph will not fit, converting to WebP frequently solves it without touching the dimensions.
When should you not use WebP?
- Anything you are submitting to an unknown system. Forms, portals, job applications, government uploads, competition entries. Use JPEG. The size difference is not worth a rejection.
- Email attachments. JPEG or PNG — whichever matches the content — because you cannot know what the recipient's client will render.
- Anything destined for print. Supply JPEG at high quality, or TIFF if asked.
- If your own tooling cannot handle it. Some CMS themes, older image libraries and scripts choke on WebP. Check before converting a whole library.
The rule of thumb, in one line
Where you control both ends, use WebP. Where somebody else's system is the destination, use JPEG for photographs and PNG for everything else.
That single sentence resolves nearly every real situation. The remaining ambiguity is almost always about whether a given platform accepts WebP, and the honest answer is that you find out by trying — which is exactly why it helps to have a converter that does not require uploading your files to a stranger's server first.
Converting between them: what to expect
| Conversion | Result |
|---|---|
| WebP → JPEG | Reliable. Slightly larger file. Transparency, if any, must be given a background colour |
| WebP → PNG | Reliable but usually much larger, since PNG stores everything exactly |
| JPEG → WebP | Smaller file, visually equivalent. The most useful conversion there is |
| JPEG → PNG | Pointless for photographs. Much larger file, and no quality is recovered |
| PNG → JPEG | Fine for photographs. Bad for anything with text, and transparency becomes a solid colour |
| PNG → WebP | Excellent for logos and cut-outs — keeps transparency, much smaller |
Two things to internalise from that table. First, converting from a lossy format to a lossless one recovers nothing — the damage from the original JPEG compression is already in the pixels, and PNG will store it faithfully in a much larger file. Second, every lossy step compounds. Convert from the original every time; do not convert a file you already converted once.
Questions
Is WebP actually better than JPEG?
For file size at equivalent visible quality, yes, typically by 25–35%, and it adds transparency and animation on top. The reason to use JPEG anyway is compatibility, not quality: some systems accept JPEG and reject WebP, and that difference matters more than the byte count.
Will converting a JPEG to PNG improve the quality?
No. It cannot recover detail that the original compression discarded. The pixels are what they are; PNG merely stores them exactly, which makes the file several times larger for no visible gain.
Why does my WebP file get rejected when the browser displays it fine?
Because displaying a format and accepting it are different capabilities. Your browser understands WebP; the server-side validation on the receiving form may only be configured for JPEG and PNG. Convert to JPEG and resubmit.
Should I use WebP for a logo?
If the logo goes on your own website, yes — it keeps transparency and is far smaller than PNG. If you are supplying it to somebody else for their use, supply PNG, since you cannot know what their tools accept. Supplying both is the pragmatic answer.
Does converting lose the transparency in my PNG?
Only if the target format cannot store it. PNG and WebP both support transparency. JPEG does not, so those pixels have to become a solid colour — which is why the conversion tool asks you which colour rather than silently choosing black.