PNG vs JPG: when to use which

TL;DR. Use PNG for screenshots, logos, and anything with sharp edges or transparency because it is lossless and supports an alpha channel. Use JPG for photographs because its lossy DCT compression produces files 5-10× smaller with no perceptible quality loss.

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.

Numeric facts

• Max dimensions: PNG up to 2³¹−1 × 2³¹−1 px (theoretical); JPG capped at 65,535 × 65,535 px (16-bit field).
• Bit depth: PNG supports 1/2/4/8/16 bits per channel + alpha; JPG is fixed at 8 bits per channel, 3 channels (no alpha). 12-bit JPG exists but is rarely supported in browsers.
• Color depth advantage: 16-bit PNG = 281 trillion colors vs JPG’s 16.7 million — meaningful only for HDR sources and gradient banding work.
• Typical file size ratio (4K photograph at quality 85): PNG ~12 MB vs JPG ~1.5 MB — about 8×.
• Typical file size ratio (UI screenshot, flat color): PNG ~80 KB vs JPG ~180 KB — PNG roughly 2× smaller.
• JPG quality vs perceptual: q=95 is visually lossless on most content; q=80 is the sweet spot for web; q=60 starts showing artifacts on faces and gradients.
• Chroma subsampling 4:2:0: stores chroma at quarter resolution, saving ~50% file size with minimal perceptual hit on photos but visible ringing on text.
• PNG compression levels: 0-9 in libpng; level 9 produces ~5-15% smaller files than level 6 but takes ~3-5× longer. oxipng and zopflipng can shave another 10-20%.
• Generation loss: JPG re-saved 10 times at q=85 drops ~3 dB PSNR vs the original; PNG is lossless so generation loss = 0.
• APNG file size vs GIF: typically 50-70% smaller than equivalent GIF at higher color depth.

Decision matrix

Sources

• W3C / ISO 15948 — Portable Network Graphics (PNG) Specification, Third Edition — w3.org/TR/png.
• ITU-T T.81 (ISO/IEC 10918-1) — Information technology – Digital compression and coding of continuous-tone still images (JPEG core spec) — itu.int.
• Wallace, G.K. — The JPEG Still Picture Compression Standard, Communications of the ACM, April 1991 — original peer-reviewed JPEG paper.