PNG vs WebP: which should you use?
By Andrew Butson · July 2, 2026 · 6 min read
Reach for WebP by default on anything that will be viewed in a browser: it matches PNG’s lossless quality and full transparency, then goes further with a lossy mode that shrinks the same image by roughly 25 to 35 percent, plus native animation PNG has never had. Keep PNG for images that need to work everywhere else: older editors, email clients, print pipelines, and any tool that predates WebP’s now-universal browser support.
Both formats are genuinely lossless-capable and both carry a full alpha channel, so the choice rarely comes down to quality. It comes down to where the file has to open.
PNG and WebP look, on paper, like they should barely differ: both are lossless by default, both support full alpha transparency, and both are open, patent-free formats. PNG arrived in 1996 as a licence-free replacement for GIF; WebP arrived from Google in 2010, aiming squarely at PNG and JPEG’s territory at once. Fourteen years apart, the newer format inherited every strength of the older one and added a genuinely lossy mode neither PNG nor its ancestor GIF ever had.
That makes this comparison different from JPEG vs PNG, where lossy and lossless serve clearly separate jobs. Here, WebP is trying to do PNG’s whole job, better. The interesting question isn’t which format produces a better picture. It’s whether the surrounding software world has caught up to WebP yet.
| PNG | WebP | |
|---|---|---|
| Compression | Lossless only | Lossy and lossless |
| Typical file size | Larger, especially for photos | Usually 25–35% smaller than PNG at equivalent quality |
| Transparency (alpha) | Yes — full alpha channel | Yes — full alpha channel, in both modes |
| Animation | No native support (APNG is an extension, rarely used) | Yes — native animated WebP |
| Browser support | Every browser, since the 1990s | Every current browser |
| Support outside browsers | Universal — decades of software | Patchy — many older editors, email clients and print tools reject it |
| Standard | Open (ISO/IEC 15948), 1996 | Open (BSD-licensed), Google, 2010 |
| Best for | Screenshots, logos, icons, line art | The same uses, smaller — plus photos on the web |
Two ways to be lossless, one way to be smaller
PNG has exactly one mode: lossless. It compresses a grid of pixels with DEFLATE, the same general-purpose algorithm behind ZIP, which reproduces every pixel exactly but doesn’t compress photographic detail especially well, because DEFLATE wasn’t designed with images in mind.
WebP’s lossless mode uses a purpose-built image compressor with better pixel prediction and entropy coding, so it typically beats PNG’s file size while still reconstructing the image exactly. Its lossy mode, adapted from the VP8 video codec, goes further still: it accepts a controlled, usually invisible loss of detail in exchange for the 25–35% size reduction that has made WebP the default export format for most modern website builders and CMSes.
Transparency and animation: WebP does everything PNG does, plus motion
Both formats store a full alpha channel, so a logo or icon keeps smooth, graduated see-through edges rather than the jagged on/off transparency of a GIF. The difference is that WebP keeps that transparency even in its lossy mode, so a logo with a soft drop shadow can have a transparent background and still be a fraction of the size of the equivalent PNG.
PNG has never supported animation on its own. Its animated variant, APNG, took years to reach browsers beyond Firefox and still isn’t as widely tooled or used as animated WebP. WebP supports animation natively, which is why it’s increasingly the format sites reach for instead of GIF as well as instead of PNG — smaller files, more colours, and proper alpha transparency in every frame.
Where PNG still wins: everything outside the browser
Every current browser, from Chrome and Firefox to Safari and Edge, displays WebP without a plugin, and has for several years. The catch is everything that isn’t a browser. Plenty of desktop image editors, especially older versions, don’t open WebP. Some email clients render it as a broken image. Print production software and stock-photo marketplaces are hit and miss. PNG has none of these problems: it’s nearly thirty years old, and every piece of image software built since has supported it.
That’s the practical dividing line. If a file’s destination is a web page, WebP wins on size with no real downside. If the file needs to survive being emailed, printed, or opened in software you don’t control, PNG is still the safer bet.
Converting between them
Morphr re-encodes the image and strips the EXIF and GPS data the original carried, whichever direction you convert. Going from PNG to WebP, choosing lossless WebP reproduces the PNG exactly at a smaller size; choosing lossy trades a small, usually invisible amount of detail for an even bigger saving.
Going from WebP to PNG, the result depends on what the WebP already was: a lossless WebP converts to an exact, larger PNG, but a lossy WebP can’t un-lose the detail its encoder already discarded. The PNG will just be a bigger, perfectly faithful copy of an already-compressed image.
A quick history of why both exist at all
PNG only exists because of a licensing dispute: the LZW compression at the heart of the original GIF format was covered by a Unisys patent, and by the mid-1990s that had made developers wary of relying on GIF at all. PNG was designed from scratch as a free, technically superior replacement, with better colour depth, real alpha transparency, and lossless compression that actually suited images rather than general-purpose data.
WebP’s origin story is different: Google built it in 2010 not to dodge a patent, but to attack file size directly, reusing intra-frame prediction techniques from its own VP8 video codec. That heritage is why WebP behaves like a hybrid — a lossless mode that plays PNG’s role, and a lossy mode that plays JPEG’s, in a single container. Fifteen years on, the format has matured from a Chrome-only curiosity into something every current browser renders without a second thought.
Choose PNG when…
- The image needs to open in software that might not support WebP — older editors, some email clients, print workflows.
- You’re producing something for a marketplace or CMS that only accepts PNG uploads.
- You want the single most universally supported lossless format, full stop.
- You’re taking a screenshot or diagram you’ll edit repeatedly outside a browser.
- You’re archiving an image and want a format guaranteed to open unchanged decades from now.
Choose WebP when…
- The image is going on a website — WebP shrinks page weight with no visible quality loss.
- You need transparency and a small file size at the same time.
- You want simple animation without GIF’s 256-colour limit.
- You control, or can specify, the software that will open the file, so browser-only support isn’t a problem.
- You’re replacing a mix of JPEG and PNG assets with one format that does both jobs.
Drop in a PNG and get back a smaller WebP with transparency intact — nothing uploaded, nothing left on a server.
Runs entirely in your browser — nothing is uploaded.
Frequently asked questions
- Is WebP always smaller than PNG?
- Almost always. Both WebP’s lossless and lossy modes typically beat PNG’s file size for the same image; PNG can occasionally compete on very simple, few-colour graphics, but for most images WebP wins.
- Does WebP support transparency like PNG?
- Yes. WebP has a full alpha channel in both its lossy and lossless modes, matching PNG’s transparency quality while usually producing a smaller file.
- Can I convert a WebP back to PNG without losing quality?
- Only if the WebP was saved in lossless mode. A lossy WebP has already discarded some detail, and converting it to PNG just locks that loss inside a larger, lossless file. It can’t recover what the WebP encoder threw away.
- Do all browsers support WebP now?
- Yes — every current version of Chrome, Firefox, Safari and Edge displays WebP natively. Software outside the browser is a different story; older editors, email clients and some print tools still don’t read it.