PNG vs JPG: when to use which

Two image formats, both 30+ years old, both still ubiquitous, both right in different situations. The rule of thumb is simple: PNG for screenshots, logos, anything with sharp edges or transparency; JPG for photographs. The reasoning underneath that rule is more interesting than the rule itself.

The headline differences

Why lossy compression wins for photographs

JPG’s compression algorithm — the discrete cosine transform (DCT), followed by chroma subsampling and Huffman coding — is engineered around the human visual system. The algorithm throws away information the eye can’t easily see:

• Chroma subsampling. Human vision is far more sensitive to brightness (luma) than to colour (chroma). JPG stores colour at half the resolution of brightness, which is invisible in normal viewing.
• Frequency-domain quantisation.Photographs contain a lot of high-frequency noise (subtle gradients, texture, sensor grain). The DCT separates the image into frequency bands; JPG quantises the high-frequency bands aggressively. You lose detail you weren’t consciously seeing anyway.

For a 4K photograph, JPG at quality 85 looks indistinguishable from the lossless original to most viewers, at one-tenth the file size. That ratio is unbeatable.

Why lossy compression fails for screenshots and logos

Flat regions and sharp edges are exactly the wrong kind of content for JPG’s frequency-domain math. The algorithm introduces ringing artefacts around hard edges (visible as faint halos near text), and the chroma-subsampling that hides nicely in a photograph becomes obvious colour-shift smears next to a saturated brand colour.

PNG’s DEFLATE compression, by contrast, is exact. A 24-bit colour is stored as a 24-bit colour. Flat regions compress beautifully because run-length encoding spots the repetition; sharp edges stay sharp. A typical UI screenshot in PNG is smaller than the same screenshot saved as JPG, because the bytes the photograph would have are dominated by the runs PNG eats for breakfast.

The transparency question

JPG has no alpha channel. A “transparent JPG” doesn’t exist; the format physically cannot store one. If you need anything to sit on top of a non-rectangular background — logos, icons, sticker-style cutouts, anything layered — PNG is the only one of the two that works.

The workaround people sometimes attempt is matching the JPG background to the destination background colour. This works for one specific destination and breaks the moment the asset is reused. Don’t do it. Use PNG or, better, a vector format like SVG.

When neither PNG nor JPG is the right answer

Three cases:

1. Vector graphics. Logos, icons, illustrations should ship as SVG when possible. Vectors scale to any resolution, stay sharp on any display, and usually compress to a few hundred bytes. PNG locks you into one resolution.
2. Modern web photographs. Use WebP (or AVIF where supported). Both formats produce 25-50% smaller files than JPG at equivalent visual quality, and both support alpha. Our JPG to WebP converter and PNG to WebP converter handle the swap in-browser. Fall back to JPG with <picture>for the small share of clients that don’t support WebP.
3. Inline UI imagery. Sometimes the right answer is to skip a separate file entirely. Our image-to-Base64 tool encodes any image as a data URI you can paste straight into HTML, CSS, or JSON. Useful when the image is small (under ~10 KB) and a separate HTTP request would slow the critical render path.

The decision tree

1. Does it need transparency? → PNG (or SVG if vector).
2. Is it a photograph or photo-like? → JPG, or WebP for the web.
3. Is it a screenshot, UI capture, or flat-colour graphic? → PNG.
4. Is it under 10 KB and used once? → Base64 inline.
5. Is it a logo or icon? → SVG. PNG as a fallback.

That covers about 95% of cases. The 5% are typically resolved by trying both formats and comparing file sizes — neither algorithm is magic, and the right answer depends on the specific content.