I Converted My Own Site's Images to JPG. The Text Got Worse — Here's the Data
I ran this site's 1200×630 share cards through PNG, JPG, and WebP at several quality levels and logged every byte. The 'just compress it to JPG' advice falls apart the moment the image contains text.
I did something this afternoon that I usually tell other people not to do: I took a batch of PNGs and blindly converted them to JPG to save space. Then I actually looked at the result, and it was worse.
The files were the social-share cards for this site — 1200×630 images with a big heading and some body text. As PNGs they sat at 60–70 KB each. "That's a bit heavy," I thought, "JPG will cut that in half." It did cut them in half. It also turned the text into something that looked like it had been photocopied through a fax machine.
So I stopped guessing and measured. I encoded each card seven different ways with Pillow and logged the exact byte count for every combination. Here is what the numbers actually say.
One representative file, measured
This is image-resizer.png — a 1200×630 card with a heading and a line of body copy:
| Encoding | File size | vs. original |
|---|---|---|
| PNG (as shipped) | 58.5 KB | — |
| PNG, re-optimized | 47.4 KB | −19% |
| JPG, quality 90 | 29.8 KB | −49% |
| JPG, quality 75 | 19.1 KB | −67% |
| JPG, quality 50 | 14.7 KB | −75% |
| WebP, quality 90 | 14.1 KB | −76% |
| WebP, quality 80 | 9.6 KB | −84% |
| WebP, quality 75 | 8.3 KB | −86% |
I ran the same test on the other six cards and the pattern barely moved. Averaged across all seven files, JPG at quality 75 landed around 22 KB, while WebP at quality 80 landed around 12 KB — roughly half the size of the JPG, at a quality you can actually ship.
So why did the JPG look bad if it was smaller?
JPEG splits the image into 8×8 blocks and throws away detail it thinks your eye won't miss. On a photo of a beach, that's a great trade. On black text sitting on a white card, it's a disaster: those sharp black-on-white edges are exactly the high-frequency detail JPEG is most aggressive about discarding, and the result is ringing and smearing around every letter. The smaller the file, the more obvious it gets. Quality 50 in the table above? The text is *technically* legible and looks noticeably rough.
WebP is smarter here. It predicts neighboring pixels instead of compressing rigid blocks, so flat areas and hard edges survive much better. At 9.6 KB the text is still crisp — which is the entire point of putting text on an image in the first place.
The rule I follow now
- Text, UI, screenshots, logos, anything with hard edges → export WebP first, PNG as the fallback. Never JPG.
- If a pipeline only does JPG → keep the PNG. An optimized PNG graphic is a better deal than a JPG that mangles your text.
- Actual photographs → the old advice is fine. JPG and WebP both work, and PNG is genuinely wasteful there.
The mistake in "just compress everything to JPG" is that half the images on a typical site are not photos. They are graphics with text, and those two categories want opposite encoders.
Reproducing it
Nothing fancy: Pillow, JPEG at quality=90/75/50, WebP at quality=90/80/75 with method=6, then measure the encoded buffer size. Two caveats worth stating plainly: these are flat graphics with text, not photographs, so don't read the ratios as photo numbers; and WebP at high quality on a *photo* behaves differently than on a UI card like this.
If you want to try it on your own files without installing anything, the Image Format Converter and Image Compressor run the same encoder in your browser and show the before/after size side by side. For the full format breakdown, the PNG vs JPG vs WebP guide goes deeper.