PNG vs JPG — a decision tree, file-size math, and when each wins

The short version

• Photograph? → JPG (quality 85, small file, no one can tell).
• Screenshot, UI, or graphic with flat colors? → PNG (smaller and sharper).
• Logo or image with transparency? → PNG (JPG literally can't do alpha).
• Hero photo on a web page? → JPG (or WebP/AVIF if the site supports them).
• Diagram, chart, or line art? → PNG (preserves sharp edges; JPG creates halos).
• Scan of a document? → PNG if the text is thin and sharp; JPG if it's a full-color photo of a page.

That's the headline. The rest of the post walks through the decision tree, the file-size math, and the edge cases where the heuristic above breaks down.

Why the two formats exist

JPG (1992) — designed for photographs

JPG (technically JPEG / JFIF) is a lossy, DCT-based codec designed around how human vision actually works: we notice brightness changes much more than color changes, and we tolerate small errors in smooth regions. JPG exploits this by converting the image to YCbCr, reducing color detail, and quantizing high-frequency components aggressively. The result: a photograph that looks identical to the original uses roughly 5–15% as many bytes as a PNG of the same image.

The cost is twofold: (1) JPG throws information away, so re-saving a JPG repeatedly accumulates loss; (2) JPG has no alpha channel — transparent pixels get flattened onto a solid background color during encode.

PNG (1996) — designed as a better GIF

PNG is lossless and palette-flexible. It uses the DEFLATE algorithm (the same compression zip and gzip use) on a pre-processed pixel stream, plus a set of filters that exploit horizontal/vertical pixel correlation. It supports indexed (8-bit palette), grayscale, and full 24-bit color, with optional alpha. It was designed to replace GIF with better compression, a proper alpha channel, and no patent encumbrance.

PNG excels on images where DEFLATE finds patterns: flat color regions, repeated pixels, horizontal/vertical gradients, sharp edges. It struggles on natural photographs, where almost every pixel differs from its neighbors — DEFLATE has nothing to compress, and the file balloons.

The decision tree

Walk through these questions top-down. Stop at the first definitive answer:

1. Does the image need transparency? Yes → PNG. JPG can't carry alpha at all. Stop.
2. Is the image a photograph (captured from a camera, even if edited)? Yes → JPG. The file will be 5–15× smaller with no visible quality loss at Q85. Stop.
3. Is the image a screenshot, UI mockup, or graphic with flat color regions? Yes → PNG. You'll get a smaller file and sharper text edges than JPG at any reasonable quality setting. Stop.
4. Is the image a logo, icon, or line art? Yes → PNG. PNG preserves the sharp edges; JPG introduces halos and ringing along lines. Stop.
5. Is the image a chart or diagram with solid shapes and text labels? Yes → PNG. Text on JPG is the most visually obvious compression artifact there is. Stop.
6. Is the image a scan of a document? With color photographs on the page → JPG. With thin black text on white, or a line-art diagram → PNG (try indexed color — an 8-bit palette PNG of a clean scan is often under 100 KB).
7. Is this a mixed-content image (UI screenshot with an embedded photograph inside it)? → PNG usually wins overall because the UI chrome dominates the pixel count, but consider cropping the photo out and shipping the two halves with different formats.

If none of those matched, the image is probably unusual — a generated texture, a rendered 3D scene, a painting. For those, just try both formats and pick whichever gives you the size/quality tradeoff you want.

File-size math — what you actually pay

The gap between PNG and JPG isn't fixed. It's a function of content. Here's what we measured across typical images at 1920×1080:

The takeaways from this chart:

• On photographs, PNG loses by an order of magnitude. A 4.2 MB PNG is a 310 KB JPG. There is no scenario where you should ship a photograph as PNG to the web.
• On UI screenshots, PNG wins by 2–3×. This surprises people — "lossless" sounds like it should always be bigger. It isn't when DEFLATE has flat color to compress.
• On charts and diagrams, PNG wins by 5× or more, and keeps text perfectly sharp. JPG produces visible ringing around text on flat backgrounds.
• On logos with transparency, JPG isn't even an option. PNG is the only answer (or SVG, if the logo is vector).

The anti-patterns

These are the four mistakes we see most often:

PNG of a photograph

Someone takes a screenshot of a photograph, or exports from Figma as PNG, or saves a camera photo as PNG "for quality." The result is a file 10–15× larger than necessary, with zero visible quality benefit because PNG is lossless against whatever pixels it's given — not against the original scene. Fix: convert to JPG at Q85.

JPG of a logo or UI screenshot

Saving a logo or screenshot as JPG produces visible DCT ringing around sharp edges — halos and color bleeding along text characters and logo outlines. The file is often largerthan the PNG equivalent, too. Fix: re-export as PNG.

Re-saving a JPG repeatedly

Every time you save a JPG, the lossy compression runs again. Crop-save-reopen-crop-save-reopen accumulates degradation. If you're editing a JPG heavily, convert to PNG (or TIFF) during the edit and export back to JPG once at the end.

PNG for a photo because "the file browser wants thumbnails"

There is no format that renders thumbnails faster in modern OSes — both Windows and macOS decode JPG and PNG equally fast. This is a myth from the 1990s. Use the right format for the content.

Where neither is right — WebP and AVIF

Both PNG and JPG are from the 1990s. Modern web delivery has two successor formats that beat both at their own games:

• WebP has lossy AND lossless modes in one format. Lossy WebP is ~25–35% smaller than JPG at matched quality. Lossless WebP (VP8L) is ~25% smaller than PNG. It supports transparency natively. Every modern browser handles it.
• AVIF goes further — ~50% smaller than JPG on photos, also supports transparency, same modern browser coverage minus iOS 15 and older.

We wrote a full comparison in AVIF vs WebP vs JPEG. Short version: if the destination accepts WebP (it does, for any modern web audience), WebP beats PNG for graphics and JPG for photos. The only reason to keep using PNG or JPG in 2026 is compatibility — the legacy CMS, the Outlook desktop client, the old job-portal form that whitelists file extensions.

Converting between them

PNG to JPG

Use our PNG to JPG tool when you have a PNG of a photograph and need smaller file size, or when the destination specifically requires JPG. The only landmine is transparency — JPG can't carry alpha, so transparent pixels get flattened onto a background color you pick. For a logo on a light web page, pick white; for dark UI, pick the dark background color directly so you don't see a halo.

JPG to PNG

Use our JPG to PNG tool when you need transparency (you'll have to paint the alpha in manually — JPG has no alpha to recover), when a destination requires PNG, or when you're about to edit the image and want to avoid generation loss during the edit cycle. Be honest: converting JPG to PNG does not improve quality. The PNG is lossless against the pixels in the JPG, which already lost information relative to the original. The file gets bigger; the quality doesn't.

How our tool compares (honestly)

Common questions

Is PNG really always lossless?

PNG the format is lossless. But PNG has a sub-format called PNG-8, which uses an indexed color palette capped at 256 entries. If your source has more than 256 distinct colors (any photograph does), encoding to PNG-8 quantizes the color down, which is a lossy step. Standard PNG-24 and PNG-32 are truly lossless. Check which mode your tool is writing.

Why is my PNG bigger than my JPG was?

Because the source was a photograph. PNG stores every pixel losslessly; JPG throws away information humans can't see. On photographs, that's a 5–15× size difference. Convert back to JPG if the destination accepts it, or ship a WebP which will be smaller than both.

Why is my JPG bigger than my PNG was?

Because the source was a UI screenshot or graphic with flat colors. JPG's DCT coding is efficient on natural textures and terrible on flat regions and sharp edges. On graphics, PNG can be 2–5× smaller than the equivalent JPG. Switch formats.

Does PNG support transparency?

Yes, fully — 8-bit alpha, every level between fully transparent and fully opaque. That's the main reason logos and icons are shipped as PNG rather than JPG. If you need transparency and want smaller files, WebP or AVIF also support it.

Does JPG support transparency?

No. The JFIF/JPEG spec has no alpha channel. When you save a transparent image as JPG, the encoder flattens transparent pixels onto a background color (often black by default, which is usually wrong). Our PNG to JPG tool surfaces a background-color picker so you can set this explicitly.

Is there ever a reason to use JPG for a screenshot?

Almost never. The exceptions: if the screenshot is dominated by a full-screen photograph (a desktop wallpaper or a movie still), the photo-like content can outweigh the UI text, and JPG will produce a smaller file. If the screenshot is mostly UI (web page, app, terminal, chart), PNG is always better.

What about SVG?

SVG is a vector format, not a raster. For logos, icons, charts generated from data, and anything else that's natively vector, SVG beats both PNG and JPG — infinitely scalable, tiny file sizes, editable with text tools. Use SVG when the source is vector; use PNG/JPG for raster images only.

Ready?

Photos → PNG to JPG. Graphics with transparency → JPG to PNG. Modern web delivery → consider JPG to WebP or JPG to AVIF instead of either, and read the AVIF vs WebP vs JPEG comparison for the full picture. Free, in-browser, no watermarks.