JPG, PNG or WebP: choosing the format that actually fits the job
Most image bloat comes from using the wrong format rather than the wrong compression. Here is what each one is built for, with the file sizes that follow from picking correctly.
Entrovix AIAug 1, 2026 8 min read
JPG, PNG or WebP: choosing the format that actually fits the job
A screenshot saved as JPG comes out blurry around the text and larger than it needed to be. A photograph saved as PNG comes out pixel-perfect and eight times the size it should be. Both are the same mistake in opposite directions, and both are extremely common.
The formats are not competing versions of the same idea. Each compresses by exploiting a different assumption about what is in the picture, and using one on the wrong kind of image defeats the assumption entirely.
What each format assumes
JPEG assumes the image is a photograph: smooth gradients, no hard edges, and detail your eye will not miss if it is approximated. It discards high-frequency information — sharp transitions between adjacent pixels — because in a photograph there are few of them and they carry little meaning.
PNG assumes the opposite. It compresses losslessly by finding runs and patterns of identical pixels, which is why it excels at flat colour, line art and text, and why it performs poorly on photographs where almost no two adjacent pixels are the same.
WebP does both. It has a lossy mode built on similar principles to JPEG and a lossless mode closer to PNG, and it is typically 25–35% smaller than either at matched quality. Every current browser supports it.
| Image | As JPG | As PNG | As WebP |
|---|---|---|---|
| Photograph, 1920×1080 | 180 – 400 KB | 1.8 – 3 MB | 120 – 280 KB |
| Screenshot with text | 150 – 300 KB, text fringed | 80 – 200 KB, text crisp | 50 – 130 KB, text crisp |
| Logo, flat colour | 40 – 90 KB, edges muddy | 8 – 25 KB, edges clean | 5 – 18 KB, edges clean |
| Photo needing transparency | Not supported | 1.5 – 3 MB | 150 – 350 KB |
Read the screenshot row twice. JPEG produces a file that is both larger and worse — the only outcome with no argument in its favour, and the single most common image mistake on the web.
Why JPEG ruins text
Text is a wall of hard edges: black pixel beside white pixel, thousands of times over. That is exactly the high-frequency detail JPEG is designed to throw away, so it spends its budget approximating the one thing that must not be approximated.
The result is the grey halo you see around letters in a compressed screenshot — ringing artefacts, where the compressor's approximation of a sharp edge overshoots on both sides. Raising the quality setting reduces it and inflates the file past what PNG would have produced losslessly.
If the image contains words that someone has to read, do not use JPEG. There is no quality setting that makes it the right choice.
The decision, in four questions
- 1Does it need transparency? If yes, PNG or WebP. JPEG has no alpha channel and will fill the transparent area with white or black.
- 2Does it contain text, line art or flat colour? If yes, PNG or lossless WebP. Anything lossy will fringe the edges.
- 3Is it a photograph? If yes, JPEG or lossy WebP. PNG will store it faithfully at many times the size, and nobody will see the difference.
- 4Is it going on a website you control? Use WebP, with a JPG or PNG fallback if you must support something ancient. It wins on size in every category.
Resolution matters more than the quality slider
Before adjusting compression, check the dimensions. A 4,000-pixel-wide photograph displayed in a 800-pixel column is carrying five times the pixels anyone will see, and no compression setting recovers that waste — it simply compresses pixels that are then thrown away by the browser.
Resize to roughly twice the display width to stay sharp on high-density screens, then compress. Doing it in that order routinely produces files a fifth the size of compressing first, at visually identical quality.
Where government and exam portals differ
Application portals frequently specify JPG and nothing else, sometimes with an exact pixel size and a KB ceiling. That instruction overrides everything above. A technically superior WebP that the portal rejects is worth nothing, and these systems are often old enough to have been written before WebP existed.
Read the instruction page for three things: the format, the pixel dimensions, and the size limit. Portals commonly report a failure on any of the three as the same generic error, so people spend an afternoon compressing a file whose dimensions were the actual problem.
What this does not cover
Recompressing an already-compressed file compounds damage rather than starting fresh. Converting a JPG to WebP keeps every artefact the JPEG stage introduced and adds WebP's own on top. Always convert from the original where you still have it.
And none of this applies to images that need to stay editable. A logo you will resize again belongs in SVG or the original vector file, because every raster format bakes in a resolution and enlarging past it cannot invent the detail back.