A flat UI screenshot I generated this morning weighs 6.6 KB as a PNG. The exact same pixels as a JPG? 56.3 KB, an 8.5x difference, with worse quality. That single number is why the "PNG vs JPG" question keeps producing confident, wrong answers.

So I stopped arguing from theory and ran the test. Four image types, every format combination, real numbers, including two traps almost nobody talks about: the JPG→PNG round-trip that quietly balloons file sizes, and the generation-loss curve where the file size lies to you while the pixels keep degrading.

Try PNG to JPG — free, no sign-up.

The short version: "photos = JPG, everything else = PNG" is directionally right, but the margins are wild: anywhere from 2x in JPG's favor to 8x against it.

The rule everyone repeats (and where it came from)

You've heard it: JPG is for photos, PNG is for graphics. Like most folk wisdom, it compresses a real engineering trade-off into a slogan.

JPG (technically JPEG) throws away information your eye tends not to miss (fine color detail, tiny brightness variations), using 8×8 pixel blocks and a quantization step that rounds frequencies toward zero. It's brilliant on organic texture. It's terrible on flat color and sharp edges, where the rounding produces visible "ringing" and blocky smudges.

PNG is lossless. Every pixel that goes in comes back out, compressed only by finding repeating patterns (the same DEFLATE family as ZIP). Flat areas and hard edges are its home turf. Complex organic texture is its nightmare: there's nothing to throw away, and not much repetition to exploit.

The slogan hides the actual question: by how much? That's what I measured.

What I actually tested

I generated four deterministic test images at realistic web dimensions, then saved each in every sensible format and setting:

A UI screenshot (1600×900): flat fills, a nav bar, sidebar, buttons, and rows of text rendered as bars, the classic "app documentation" image.
A synthetic photo (1600×1000): gradient sky, sun haze, mountain silhouettes, film grain noise, slight blur. Organic detail everywhere, no hard edges except a few.
A flat logo (800×800): solid dark background, thick colored circles and polygons, crisp lines.
A photo with text overlay (1600×1000): the synthetic photo plus a black caption band with white "text" bars, the social-media/meme case that straddles both worlds.

Every file was saved with optimized encoders at quality 85 (and 95/75 for the photo, to see the quality dial's effect). Then I ran the round-trip and re-save experiments on top. No stock photos, no hand-waving. Every number below is from an actual file on disk.

Result 1: Screenshots (PNG wins by 8.5x, and it's not close)

The same 1600×900 screenshot, saved four ways:

PNG: 6.6 KB
JPG at quality 85: 56.3 KB (8.5x bigger)
JPG at quality 75: 50.8 KB (still 7.7x bigger, dropping quality barely helps)
WebP at quality 85: 7.1 KB

Read that second bullet again. Lowering JPG quality from 85 to 75 recovered only 5.5 KB, because the bloat isn't from fidelity; it's from JPEG's noise injection around every sharp transition. Text edges, button borders, the boundary between the nav bar and the page: each one gets a halo of compression garbage that costs real bytes.

And that garbage is visible. Zoom a JPG screenshot to 300% and the text edges shimmer with gray mosquito noise. The PNG stays pixel-perfect at any zoom, at a fraction of the size.

If you take one thing from this post: never save screenshots as JPG. You pay 8x the bandwidth to make the image look worse.

Result 2: Photos (JPG wins by 2.4x, and PNG has a dirty secret)

The photo flips the table, but not as hard as you'd guess:

JPG at quality 85: 53.4 KB
WebP at quality 85: 21.3 KB (2.5x smaller than JPG)
PNG: 128.2 KB (2.4x bigger than JPG q85)
JPG at quality 95: 131.3 KB

Here's the dirty secret in that list: the lossless PNG is even bigger than a near-transparent JPG at quality 95. Lossless compression of organic grain simply has nothing to bite into: every noise pixel is "unique information" that must be preserved verbatim.

Quality 85 vs 75 tells the real story of the JPG dial: 53.4 KB down to 34.0 KB, a 36% cut for quality loss most people can't find without a side-by-side zoom. That's why 80-85 is the sweet spot for web photos; below ~75 you start seeing 8×8 blocks in smooth gradients like skies.

(For your own photo conversions, the PNG to JPG converter runs entirely in your browser, which is handy when a design tool exports PNG and you need the smaller web-friendly file.)

Result 3: Logos and line art (PNG's fortress)

The logo test is the most lopsided result of the day:

PNG: 8.2 KB
WebP (lossy, q85): 20.4 KB (2.5x bigger)
JPG at quality 85: 44.2 KB (5.4x bigger)

Two things worth knowing here. First, this is the one case where even WebP loses to PNG: lossy encoders still pay for those razor-sharp edges, and PNG's pattern-mapping eats flat shapes for breakfast.

Second, the JPG logo isn't just big; it's broken in a way the file size can't express. Those crisp circle outlines come out fringed with colored ghosting, and the solid background gains a subtle checkerboard of block boundaries. On a brand asset, that's disqualifying.

Logos, icons, diagrams, charts with few colors: PNG, every time. If you also need transparency (which JPG literally cannot store), there was never a choice to begin with.

Result 4: The hybrid (photo with text overlay)

Real-world images love to mix categories: a photo with a caption, a product shot with a price badge, a meme. I added a black caption band with white text bars to the photo:

WebP at q85: 20.7 KB
JPG at q85: 59.4 KB
PNG: 116.1 KB

JPG still beats PNG handily (the photo dominates the frame), but this is the case where JPG's weakness bites: the caption text grows the file by ~6 KB versus the clean photo (59.4 vs 53.4), and zooming in shows faint ghost fringes around the white letters.

The practical read: for social graphics and photo-plus-text, WebP is the honest answer, with JPG as the compatibility fallback. PNG only earns its size here if the text must stay surgically crisp (say, a step-by-step tutorial figure).

The round-trip trap: "saving" a JPG as PNG makes it bigger

Now the trap I promised. A frighteningly common ritual: someone has a JPG, fears further quality loss, and converts it to PNG to "lock in" the quality.

I ran it both ways:

The screenshot: 6.6 KB PNG → 56.3 KB JPG → 32.5 KB "PNG": 5x bigger than the original PNG it came from, and it permanently freezes the JPG's artifacts into the file.
The photo: 128.2 KB source → 53.4 KB JPG → 337.7 KB "PNG": the round-tripped PNG is 2.6x bigger than the pristine original PNG, and bigger than every JPG in the test.

The mechanics are cruel. JPG compression adds noise around edges; PNG is lossless, so it dutifully preserves every artifact pixel, and noise is the worst possible input for pattern-based compression. You get a file that's bigger than either format's honest output, with quality that can never improve.

Converting JPG to PNG doesn't undo JPEG damage; it embalms it. The only legitimate reasons are needing transparency support or a downstream tool that demands PNG; if that's your situation, the JPG to PNG converter does it locally in your browser. Just know what you're getting: a bigger file at identical (artifacted) quality.

Generation loss: the file size lies while pixels decay

Here's the most counterintuitive finding. I took the screenshot and re-saved it as JPG five times at quality 85, the classic "edit, save, edit, save" spiral of doom.

The file size went nowhere: 56 → 57 → 57 → 57 → 57 KB.

By the numbers alone, nothing is happening. But I also measured pixel-level drift from the pristine original each generation:

Generation 1: RMS error 2.47, creeping up from 2.06
Generation 3: RMS 2.87
Generation 5: RMS 3.01, with a maximum channel error of 76 (on a 0-255 scale) right at text edges

Two lessons fall out. First, decay accumulates fastest in the first re-save and then plateaus, each generation converges toward the same "JPEG-ified" version of the image, so the fifth save costs less than the first. That's more forgiving than the folklore suggests.

Second, and this is the one to remember, file size is not a quality gauge. A stable 57 KB across five saves hides visible ghosting around every letter. If you must re-encode repeatedly (say, iterative edits in a tool that only exports JPG), keep an untouched master and always export from it, never from the previous export. When a master needs to stay pristine, compress images in your browser with a tool that never re-uploads or re-compresses behind your back.

Where WebP fits (and doesn't)

WebP appeared in every test above, and the pattern is consistent: within ~5 KB of the best format everywhere, dominant on photos and hybrids, slightly behind PNG on flat graphics.

Photo: 21.3 KB vs JPG's 53.4, 60% smaller than JPG at the same quality setting
Photo + text: 20.7 KB, the clear winner of the hybrid case
Screenshot: 7.1 KB vs PNG's 6.6, close enough that either is fine
Logo: 20.4 KB vs PNG's 8.2, the one clear loss

Every current browser (Chrome, Firefox, Safari, Edge, mobile included) has supported WebP for years now; the format-compatibility fears are mostly folklore from 2019. If you run a site, converting existing PNG/JPG assets is one of the cheapest speed wins available, the PNG to WebP converter handles it client-side, no upload queue.

The honest exception is the same as PNG's: hard-edged flat art with few colors, where lossless PNG remains untouchable.

The actual decision rules

Strip away my experiment scaffolding and here's the whole topic in six bullets:

Screenshots, UI captures, tutorials: PNG. JPG costs ~8x the bytes for worse quality.
Photos for the web: WebP first, JPG at quality 80-85 as the safe fallback. PNG is 2.4x bigger for zero visible gain.
Logos, icons, line art, anything with transparency: PNG. Not negotiable: JPG can't even store transparency.
Photo + text overlays / social graphics: WebP, then JPG. Check text edges at 100% zoom before shipping.
Never convert JPG → PNG to "protect" quality: it triples the size and preserves the damage.
Archive/editing masters: keep a lossless original (PNG or the tool's native format); export compressed copies from it, always.

One more lever that beats them all: dimensions. A 1600px-wide image displayed at 800px wastes bytes no codec can recover. Halving dimensions cuts file size roughly 4x, before compression even enters the conversation. Resize first (free image resizer, runs offline in your browser), then pick the format.

Every conversion and compression tool mentioned above lives in the free image tools hub, all browser-side, nothing uploaded.

FAQ

Is PNG or JPG better for websites?

For photos, JPG (or WebP): my test showed PNG is 2.4x larger at indistinguishable quality. For screenshots, logos, and graphics, PNG: it was 8.5x smaller than JPG and pixel-perfect. Match the format to content, not to a blanket rule.

Is PNG higher quality than JPG?

PNG is lossless: it preserves pixels exactly. JPG is lossy by design. But "higher quality" only matters if the source content shows JPG's artifacts: on photos at quality 85+, most people cannot tell them apart. On text and sharp edges, the difference is visible immediately.

Why did my file get bigger when I converted JPG to PNG?

Because PNG losslessly preserves all the compression noise JPG injected around edges, and noise doesn't compress. In my test the round-trip PNG was 2.6x bigger than the original PNG and 6x bigger than the JPG. It also permanently locks in the JPG artifacts.

Does re-saving a JPG repeatedly keep getting worse?

Yes, but with diminishing returns: my five-generation test showed pixel drift rising quickly at first, then plateauing (RMS 2.47 → 3.01), while file size stayed flat at ~57 KB. The first re-save does most of the damage; just don't use size as a quality gauge, because the visible edge ghosting grows even when KBs don't.

Which format supports transparency?

PNG and WebP do; JPG does not: its spec has no alpha channel. Any "transparent JPG" is actually a PNG/WebP/GIF with a mislabeled extension, and JPG exports from transparent sources get flattened onto a solid background.

When should I use WebP instead of both?

On photos and photo-plus-text images: my test had WebP 60% smaller than JPG at equal quality. On flat graphics, PNG still wins (8.2 KB vs 20.4 KB on my logo). All current browsers support WebP, so it's the default for photographic content on the web.