PNG vs JPG

The short answer

PNG and JPG (JPEG) are the two oldest universally-supported web image formats and they solve different problems. PNG is lossless and supports transparency; JPG is lossy and dramatically smaller for photographic content. The choice is structural: PNG for graphics with hard edges or transparency; JPG for photos and other continuous-tone content; WebP or AVIF for either case when delivery weight matters.

This is the classic image-format question every web developer encounters within their first week. The answer holds up despite three decades of format churn around it.

The shape of the decision

The decision tree is short and reliable:

• Does the image have hard edges, flat colour fills, or transparency? → PNG.
• Is it a photograph or other continuous-tone image with no transparency? → JPG.
• Do you control the delivery pipeline and care about page weight? → consider WebP (lossless for PNG cases, lossy for JPG cases). See WebP vs PNG and WebP vs JPG.

The same logic that makes PNG good for logos makes JPG terrible for them. The same logic that makes JPG good for photos makes PNG wasteful for them. Each format is the wrong choice for the other's content type.

How they differ technically

PNG and JPG were designed for different content classes and took fundamentally different compression approaches.

JPG: lossy, photographic

JPG (officially JPEG) was specified in 1992 by the Joint Photographic Experts Group. The pipeline:

1. Convert RGB to YCbCr (separating luminance from chrominance).
2. Downsample the chrominance channels (the human eye is less sensitive to colour detail than to luminance detail).
3. Apply the Discrete Cosine Transform to 8×8 pixel blocks (representing them in the frequency domain).
4. Quantise the DCT coefficients (the lossy step — the quality factor controls how aggressively).
5. Huffman-code the quantised coefficients.

Each step discards information the visual system is least likely to notice. The aggregate is a compression scheme that produces small files for photographic content and visible artefacts for content with hard edges or text overlays.

PNG: lossless, graphics

PNG was specified in 1996 in response to a patent dispute over GIF. Its design priorities were lossless compression, full 24-bit colour, 8-bit alpha transparency, and a royalty-free codec. The pipeline:

1. Filter each row of pixel data using one of five predictor functions (the row becomes much more compressible after filtering).
2. Compress the filtered data with DEFLATE (the same algorithm as ZIP).

The output is bit-identical to the source. PNG never discards information; it just represents the same content more compactly. For content with flat colour fills, hard edges, or limited palettes, PNG's compression is excellent. For continuous-tone photographic content, it's wasteful — every pixel is slightly different from its neighbours, leaving little for the predictor and DEFLATE to exploit.

For full format detail, see PNG Format and JPG Format.

File size by content type

The dramatic case: a 1600×900 hero photograph.

For a photo, the PNG is 15× larger than the JPG. There is no scenario where serving the PNG instead is the right call.

The opposite case: a 240×80 brand logo with transparency.

For a logo, JPG isn't an option. PNG works; lossless WebP works better.

Where each wins decisively

PNG wins

• Logos, icons, brand assets. Hard edges, flat fills, transparency.
• Screenshots with text. Anti-aliased text under lossy JPG produces ringing artefacts.
• Charts, diagrams, line art. Flat regions and sharp transitions compress well in PNG and badly in JPG.
• Anything requiring transparency. JPG has none.
• Pixel art and limited-palette content. PNG's indexed-colour mode is dramatically efficient.
• Master files that will be edited further. Lossless preservation matters when more lossy passes are coming.

JPG wins

• Photographs. Continuous-tone content where DCT-based compression shines.
• Renderings with smooth gradients. 3D renders without UI overlays, generative imagery.
• Scanned documents (where text isn't critical). Quick visual reference at small file size.
• Any large image where file size matters more than perfect fidelity. Hero photos, gallery thumbnails, background imagery.
• Email attachments. PNG photos balloon attachment sizes; JPG is the polite default.
• Marketplace uploads where the platform will re-encode anyway. Why send a 4 MB PNG that becomes a 200 KB JPG on receipt?

Transparency: the determinant

The single most decisive feature difference. JPG cannot encode an alpha channel. Content requiring transparency must use PNG (or WebP, or AVIF).

This is why PNG dominates the logo / icon / UI graphic ecosystem. There's no JPG path that produces a logo with anti-aliased edges over a non-white background. PNG was designed for this; JPG never could be.

For complex transparency on photographic content (a product photo cut out from a background), the historically expensive option was PNG (typically 500 KB – 2 MB for a single product shot). The modern option is WebP with lossy RGB and lossless alpha, which produces a 50–100 KB file with the same quality.

Quality: the lossy trade-off

JPG's lossy compression is content-dependent in its effect.

• q=95–100: artefacts effectively invisible. Diminishing returns above q=92.
• q=80–94: visually indistinguishable from source on typical displays.
• q=70–79: differences visible only on close inspection. Acceptable for thumbnails and body imagery.
• q=50–69: artefacts visible to attentive viewers.
• q=1–49: visible degradation. Use only for decorative or deliberately compressed content.

PNG has no quality knob. The output is bit-perfect identical to the input. Encoding settings affect file size and encoding time but not visible quality.

For content where any quality loss is unacceptable — archival masters, content for further editing, content with critical fine detail — PNG is the safe default.

File size optimisation within each format

Both formats benefit from modern optimisation tooling:

PNG:

• pngquant — lossy quantisation to indexed colour. 50–80% smaller files with negligible visible loss for content with limited palettes.
• oxipng — lossless re-encoding. Modern replacement for optipng. 5–15% smaller than default encoders.
• zopflipng — maximum lossless DEFLATE compression. 3–8% smaller than oxipng at much longer encoding time.

A pipeline of pngquant → oxipng (lossy quantisation followed by lossless squeezing) produces the smallest practical PNG output.

JPG:

• MozJPEG — Mozilla's encoder fork. 10–15% smaller files than libjpeg-turbo at equivalent visual quality. The right encoder for any production JPG pipeline.
• Progressive encoding — slightly smaller files and better perceived loading. The default for modern encoders.

For migration to WebP or AVIF (which beat both PNG and JPG decisively on size for their respective content types), see WebP vs PNG and WebP vs JPG.

Browser support

Both formats are universally supported. Every browser ever shipped has rendered PNG since 1996 (and JPG since the early 1990s). There is no compatibility consideration.

The fallback to PNG or JPG from a more modern format (WebP, AVIF) is the standard pattern:

<picture>
  <source type="image/webp" srcset="/img/photo.webp" />
  <img src="/img/photo.jpg" alt="..." width="1200" height="675" />
</picture>

The browser uses WebP when supported; falls back to JPG (or PNG) otherwise. See WebP Browser Support.

Migration considerations

If you're auditing a site that mixes PNG and JPG:

• PNG photos. Always wrong. Re-encode as JPG at q=82 or as lossy WebP at q=80. Massive size wins.
• JPG logos / icons. Almost always wrong. Look for JPG ringing around text or banding on flat fills — both telltale signs. Re-encode as PNG or lossless WebP.
• PNG screenshots. Often correct but worth checking — a screenshot of mostly photographic content (a photo in a UI) may compress better as JPG.
• JPG charts and diagrams. Wrong. Re-encode as PNG or lossless WebP. Lossy compression of charts produces visible artefacts around axis labels and gridlines.

Spot-checking format choices on existing sites consistently finds 10–20% of images in the wrong format. Auditing and correcting is one of the cheapest performance wins available.

Recommendation

For new content, use the structural rule:

• Content with hard edges, flat fills, or transparency → PNG (lossless, universal) or lossless WebP (smaller, ~97% support).
• Continuous-tone photographic content → JPG (universal) or lossy WebP at q=78–82 (smaller, same quality).
• Both directions, when delivery weight matters → WebP-with-fallback for browsers; PNG/JPG for non-browser distribution.

For audit work on existing content, scan for format mismatches and fix them first. The wins are larger than tuning quality settings or adopting newer formats.

Common questions

Is PNG always lossless?

The PNG format is always lossless in the technical sense — the encoded image decodes to bit-identical pixels. PNG files can be made smaller through lossy preprocessing (palette quantisation via pngquant), but the PNG itself remains a lossless container of whatever pixels you feed it.

Why is my PNG photo so large?

Because PNG is a lossless format and photographs have high pixel entropy. Every pixel is slightly different from its neighbours, leaving little for PNG's prediction-and-DEFLATE pipeline to exploit. Photos are the wrong content for PNG. Use JPG or WebP.

Why does my JPG logo look fuzzy around the text?

Because JPG's DCT-based compression produces ringing artefacts at high-contrast edges. The artefacts are most visible around anti-aliased text and around lines on flat backgrounds. Use PNG or lossless WebP for logos.

Does PNG support animation?

No. The Animated PNG extension (APNG) does, but it's a separate (backwards-compatible) format. Most "animated PNG" use cases are now better served by animated WebP or short MP4 video.

Should I migrate everything to WebP?

For browser delivery, almost always yes. For files distributed outside the browser (email, downloads, document embeds), keep PNG and JPG as the universal defaults. See WebP vs PNG and WebP vs JPG for the migration framework.

Convert your images

• PNG to WebP — convert PNG library to WebP
• JPG to WebP — convert JPG library to WebP
• WebP to PNG — convert WebP back to PNG
• WebP to JPG — convert WebP back to JPG

Further reading

• PNG Format — technical detail on PNG
• JPG Format — technical detail on JPG
• WebP vs PNG — the modern alternative to PNG
• WebP vs JPG — the modern alternative to JPG
• Lossy vs Lossless Compression — the underlying mode-choice framework
• WebP Optimisation — broader performance walkthrough