JPG vs WebP: which gives better quality?
By Andrew Butson · July 2, 2026 · 6 min read
At the same file size, WebP produces a noticeably sharper image than JPEG. Put the other way round, WebP needs a file that’s roughly 25 to 35 percent smaller to match JPEG’s quality. That makes WebP the better default for anything published on the web. JPEG remains the safer choice when a file has to open in something old, offline, or outside your control: a print shop, an ageing phone, or software written before 2010.
Both are lossy formats by default, so neither one is a “perfect” copy of the original. The difference is how efficiently each spends the bits it keeps.
JPEG and WebP solve the same problem, shrinking a photograph without a visible loss of quality, eighteen years apart. JPEG, standardised in 1992, remains the most universally recognised image format ever created: every camera, browser, phone and printer since the 1990s understands it. WebP, released by Google in 2010, was built specifically to beat JPEG (and PNG) at their own jobs, using compression techniques JPEG’s committee never had access to.
The technical gap between them is real and measurable, but so is the compatibility gap running the other way. WebP is still, in software terms, the newer arrival.
| JPG | WebP | |
|---|---|---|
| Compression | Lossy only (DCT) | Lossy and lossless |
| Typical size at equal quality | Baseline | Usually 25–35% smaller |
| Transparency | No | Yes — full alpha channel |
| Animation | No | Yes — native animated WebP |
| Released | 1992 | 2010 |
| Browser support | Every browser, always | Every current browser (Safari added support in 2020) |
| Support outside browsers | Universal — cameras, printers, decades of software | Patchy — some older phones, apps and print tools reject it |
| Repeated editing | Degrades a little each re-save | Lossless mode doesn’t; lossy mode degrades like JPEG |
Why WebP compresses photos more tightly
JPEG compresses an image in independent 8×8 blocks: each block is transformed and quantised on its own, with no knowledge of its neighbours. WebP’s lossy mode, adapted from the VP8 video codec, predicts each block from the blocks already decoded around it before compressing what’s left over: the same trick video codecs use to squeeze redundancy out of a sequence of frames, applied here to the redundancy between neighbouring patches of a single image.
That extra prediction step is where WebP’s advantage over JPEG comes from: for the same visual quality, it typically needs 25 to 35 percent less data, because it’s compressing less genuinely new information per block. The gap is most visible at everyday web-quality settings; right at the top of the quality range, where both formats are barely compressing at all, the difference narrows.
A newer format means a shorter compatibility record
JPEG has had over thirty years to become the one image format nothing rejects: digital cameras write it natively, every browser since the 1990s displays it, and every printer, fax machine and photo kiosk understands it. WebP has had a little over a decade, and for years that decade came with an asterisk: Safari didn’t support WebP at all until 2020, which meant a meaningful slice of desktop and mobile browsers couldn’t display it without a plugin.
That gap has closed in browsers — Chrome, Firefox, Safari and Edge all display WebP natively now. It hasn’t fully closed everywhere else. Some older phone galleries, desktop image viewers, office suites and print production tools still don’t recognise a .webp file, which is the usual reason someone downloads an image from a modern website and then needs to convert it back to JPEG before it’ll open somewhere else.
Transparency and animation: features JPEG has never had
JPEG has no alpha channel and never has. Every JPEG is a solid, opaque rectangle. WebP supports full transparency in both its lossy and lossless modes, and native animation on top of that, so it can replace not just JPEG’s job but GIF’s as well. None of that changes the core comparison for ordinary photographs, but it’s a real reason modern sites default to WebP rather than reaching for JPEG and PNG separately.
What happens when you convert
Converting a JPEG to WebP is a straightforward re-encode: Morphr decodes the JPEG and writes it out again in WebP’s more efficient format, honouring a quality slider, and strips the EXIF data along the way. Because both formats are lossy, this is a second compression pass on data that’s already lost some detail once, usually invisible, but not literally “free” the way a lossless conversion would be.
Converting a WebP back to JPEG is the more common real-world need, because it’s the direction compatibility problems run in: someone saves an image from a website, it comes down as .webp, and the next tool they need to use doesn’t accept it. If the WebP had a transparent background, that gets flattened onto a solid colour in the JPEG, since JPEG has nowhere to put transparency.
Two committees, two decades apart
JPEG was standardised by the Joint Photographic Experts Group, a committee working under ISO and ITU-T, and it shipped in an era when a modem measured its speed in kilobits, and every byte a compression scheme could save mattered enormously. That constraint produced a format that is simple, fast to decode even on old hardware, and understood by essentially every piece of imaging software written since.
WebP came from a single company chasing a single metric: how much smaller can a web page’s images get without anyone noticing. Google had already solved a version of this problem for video with VP8, and WebP is largely that codec’s intra-frame compression repurposed for still images. It’s a narrower, more modern piece of engineering than JPEG, and it shows in the numbers. But it also means WebP inherited none of JPEG’s three-decade head start in hardware and software support.
Choose JPG when…
- The image needs to open on old hardware, in offline software, or at a print shop.
- You’re shooting or exporting from a camera that only writes JPEG.
- A form, marketplace or app you don’t control only accepts JPEG.
- Maximum compatibility matters more than shaving off file size.
- You’re archiving photos somewhere you can’t guarantee future software support for WebP.
Choose WebP when…
- The image is going on a website and load time matters.
- You want a smaller file at the same visual quality, with no other trade-off.
- You need transparency or simple animation alongside photographic compression.
- You control, or can specify, the software that will open the file.
- You’re optimising a whole site’s images and want one format for photos and graphics alike.
Re-encode a JPEG as a smaller WebP without uploading it anywhere — quality slider included.
Runs entirely in your browser — nothing is uploaded.
Frequently asked questions
- Is WebP actually better quality than JPEG?
- At the same file size, yes — WebP typically looks sharper because its prediction-based compression wastes fewer bits than JPEG’s independent-block approach. Put another way, WebP can match JPEG’s quality at a file that’s usually 25 to 35 percent smaller.
- Why won’t my WebP image open in some apps?
- WebP is a newer format, and plenty of older or niche software (some phone galleries, desktop viewers, office suites and print tools) was built before WebP existed or simply never added support. Converting it to JPEG fixes that instantly.
- Does converting a JPEG to WebP lose more quality?
- A little, in principle — both are lossy formats, so re-encoding a JPEG as WebP is a second compression pass on data that’s already lost some detail. At a sensible quality setting the loss is invisible, but it isn’t a perfect, lossless step.
- Do all browsers support WebP now?
- Yes. Chrome and Firefox supported it early on; Safari was the last major holdout and added support in 2020. Every current browser displays WebP without a plugin.