June 27, 2026
JPG, PNG, and WebP: Choosing the Right Image Format
Format choice is a tradeoff between file size, fidelity, and what the image actually contains. Photographs, UI screenshots, and transparency each want a different format — and re-encoding lossy images repeatedly quietly destroys quality.
Picking an image format is a tradeoff between file size, visual fidelity, and what the image actually contains. The three formats that ship with every browser — JPG, PNG, and WebP — cover almost every web use case, and choosing correctly can cut a page's weight in half with no visible difference. Choosing badly does the reverse: a photograph ballooning to ten times its necessary size, or a logo acquiring blurry halos around every edge.
JPG: lossy, built for photographs
JPG throws away information the human eye is bad at noticing, which is why a 200 KB photograph can compress to 30 KB and still look clean. It is lossy by design — every save discards more data, a point we will come back to. JPG has no alpha channel, so there is no transparency, which immediately rules it out for logos and UI elements that sit on top of varied backgrounds.
Where JPG shines is photographs and painterly images with smooth gradients and lots of color variation. Where it fails is sharp edges, text, flat color blocks, and anything with hard transitions. Push the compression too far and you see the classic JPG artifacts: blocky ringing around edges, color bleeding, and banding in gradients. A screenshot of a text-heavy interface saved as JPG is the canonical mistake — the text looks smeared at any compression level that actually saves space. Quality settings around 75 to 85 are the usual sweet spot for photographs; below 70 the artifacts become obvious, above 90 the file grows fast for little visible gain.
PNG: lossless, built for sharp edges and transparency
PNG is lossless and supports a full alpha channel, which is why it dominates UI assets, logos, line art, diagrams, and screenshots of text. A one-pixel boundary stays exactly one pixel, and transparency just works. The cost is size: PNG's lossless compression has nothing to throw away, so it is poor on the noise and fine detail of real-world photographs. A photo that weighed 30 KB as a JPG can balloon to 300 KB as a PNG with no visible improvement, and sometimes a visible downgrade if it started life as a JPG.
The rule for PNG is simple: use it when every pixel matters and when transparency matters, and use something else for photographs.
WebP: smaller, with a caveat or two
WebP supports a lossy mode (typically smaller than JPG at equivalent quality) and a lossless mode (typically smaller than PNG), plus alpha transparency in either mode. For a typical web page, converting assets to WebP is the single largest free size win available — often 25 to 35 percent smaller than the JPG or PNG it replaces, sometimes more. Browser support is now effectively universal across modern browsers.
The caveats are practical rather than fundamental. Some older image pipelines, certain CMS workflows, and a handful of email clients still expect JPG or PNG, and WebP's lossy mode is not always a strict improvement over a carefully tuned JPG at very high quality. The right move is to measure rather than assume — convert, compare at the same perceived quality, and keep whichever is actually smaller. The image converter and compress-image tools handle this round trip without leaving the browser.
AVIF is the other modern format worth knowing. It usually beats WebP on file size for photographs and supports HDR and wider color gamuts, at the cost of noticeably slower encoding. Browser support is good but not yet as universal as WebP, so AVIF is typically served as an additional source ahead of WebP inside a picture element rather than as a replacement for it. For animated content, reach for a short video — MP4 or WebM — instead of an animated GIF; the size difference is often an order of magnitude, and the quality is higher.
Re-encoding and generation loss
Every lossy re-save throws away more data. Open a JPG, edit it, save it as JPG again, repeat a few times, and you can watch the quality slide — compression artifacts compound on each other, a process called generation loss. The same applies to lossy WebP. Two practical rules follow from this:
- Keep a lossless master — the original camera file, a PNG, or a RAW export — and export to a lossy format once, at the end of the pipeline.
- Never run lossy to lossy to lossy in a chain. Convert from the master each time, not from the previous compressed export.
Try it: Image Compressor
Shrink JPEG or WebP file size with a live quality preview, right in your browser.
Serving modern formats with a fallback
When you serve WebP, keep a JPG or PNG fallback and let the browser pick using a picture element:
<picture>
<source srcset="/img/hero.webp" type="image/webp">
<img src="/img/hero.jpg" alt="Hero photograph" width="1200" height="800" loading="lazy">
</picture>
The browser tries each source in order and uses the first it understands, so modern browsers get the smaller WebP while anything older transparently falls back to the JPG. No JavaScript feature detection required.
Choosing in one paragraph
Photograph with smooth gradients and lots of color — JPG or WebP lossy. UI asset, logo, screenshot of text, or anything needing transparency — PNG or WebP lossless. Serving to modern browsers and you care about bytes — WebP, with a JPG or PNG fallback for the long tail. And whatever you ship, keep a lossless master so you are never re-compressing an already-compressed file.