Pick the wrong image format and a page that should weigh 200 KB instead weighs 4 MB. Pick the right one and you save bandwidth, rendering time, and the user's patience. The JPG versus PNG decision is the most common branching point in a web image pipeline, and almost every team gets it wrong in at least one place: photographs saved as PNG, screenshots saved as JPG, logos with visible compression halos, gradients with banding. This article is a working engineer's guide to the actual difference between the two formats, the math behind their compression behavior, and the production rules that should govern when you reach for each one.

A Short History of the Two Formats

JPEG, formally ISO/IEC 10918-1, was published in 1992 by the Joint Photographic Experts Group, a working group of ISO and the ITU. It was designed to compress continuous-tone photographs efficiently for slow modems and small disks. The format relies on a Discrete Cosine Transform, perceptual quantization, and Huffman entropy coding. The decisions made by that committee in the late 1980s remain in every JPG file shipped today.

PNG was specified in 1996 as a direct response to a Unisys patent claim on the LZW algorithm used inside GIF. The PNG Development Group, led by Thomas Boutell, designed a royalty-free lossless format using DEFLATE compression and a typed chunk structure. RFC 2083 standardized it in 1997, and ISO/IEC 15948 ratified the second edition in 2003. Where JPEG was tuned for photographs, PNG was tuned for graphics, screenshots, and any image where every pixel must survive the encode unchanged.

"The DCT is the workhorse of image compression because it concentrates energy into a small number of low-frequency coefficients, which can then be quantized aggressively without the eye noticing." Gregory K. Wallace, ACM Communications, April 1991, the original JPEG paper.

How JPG Compression Actually Works

A baseline JPG file is the output of a five-stage pipeline. Understanding the pipeline explains every artifact you will ever see in a JPG.

The encoder first converts RGB pixels to YCbCr, separating luminance (Y) from blue-difference and red-difference chrominance (Cb, Cr). It then subsamples the chroma channels, typically to half resolution in both axes (4:2:0), exploiting the fact that the human visual system is roughly four times more sensitive to luminance edges than to chroma edges. Each channel is split into 8 by 8 blocks, and a forward Discrete Cosine Transform is applied to each block, converting 64 spatial samples into 64 frequency coefficients. A quantization table divides each coefficient by an integer, rounding the high frequencies to zero, which is where the lossy step happens. Finally, the quantized coefficients are zigzag scanned, run-length encoded, and Huffman compressed.

The quality factor in tools like libjpeg is a scalar multiplier on the quantization table. Quality 100 keeps the table near unity and the file is large but visually exact. Quality 75 is the libjpeg default and is generally indistinguishable from the original on typical photographs. Quality 50 starts to show ringing on sharp edges. Quality 25 looks like a 2003 webcam.

# Inspect quantization tables and structure
djpeg -verbose -verbose photo.jpg > /dev/null

# Re-encode at a measured quality factor with mozjpeg
cjpeg -quality 82 -progressive -optimize -outfile out.jpg in.ppm

# Lossless rotation, no re-encode
jpegtran -rotate 90 -copy all in.jpg > out.jpg

How PNG Compression Actually Works

PNG is fundamentally different. There is no transform, no quantization, no perceptual model. The encoder applies one of five line filters (None, Sub, Up, Average, Paeth) to each scanline, choosing the filter that produces the longest runs of similar bytes. The filtered byte stream then goes through DEFLATE, which is LZ77 sliding-window dictionary compression followed by Huffman coding. The result is byte-exact reversible.

The compression level in PNG (zlib level 0 to 9) trades encoder CPU for file size, but it never trades pixel fidelity. Every PNG decode produces the exact bytes the encoder wrote.

# Maximum-effort optimization with zopfli backend
zopflipng -m --lossy_transparent in.png out.png

# Strip metadata and recompress
optipng -o7 -strip all in.png

# Inspect chunks and bit depth
pngcheck -v image.png

The Decision Table

The following table summarizes the quantitative differences that should drive your choice in a real pipeline.

PropertyJPG (JPEG baseline)PNG (truecolor)
Compression modelLossy, DCT plus quantizationLossless, DEFLATE
Typical photo file size at 1920x1080200 to 600 KB at q822 to 5 MB
Color depth8 bits per channel, YCbCr8 or 16 bits per channel, RGB
Alpha channelNot in baselineYes, 1, 2, 4, 8, or 16 bits
Reopen and resave fidelityGenerational loss every saveByte-identical
Best content typePhotographs, gradients, organic texturesScreenshots, logos, line art, text
Decode speedFast, hardware-accelerated on most devicesFast, but larger files mean more I/O
Maximum dimensions65535 by 65535 pixels2147483647 by 2147483647 pixels
Standard referenceISO/IEC 10918-1 (1992)ISO/IEC 15948 (2003), RFC 2083
A second table that often surprises teams: file size at parity perceptual quality on a typical 4 megapixel photograph from a phone camera.
Format and settingTypical sizeSSIM vs original
Source PNG 24-bit12.4 MB1.000
PNG via optipng -o79.8 MB1.000
JPG quality 951.6 MB0.998
JPG quality 85 (mozjpeg)540 KB0.992
JPG quality 75320 KB0.984
JPG quality 60210 KB0.969
The lesson is that for photographs, PNG offers no perceptual benefit at twenty times the byte cost.

When PNG Wins Decisively

PNG is the correct choice in five well-defined cases.

The first is screenshots of user interfaces. UI contains sharp edges, anti-aliased text, and large flat regions, all of which DEFLATE compresses tightly and JPEG mangles. A 1440 by 900 pixel screenshot of a code editor is typically 80 KB as PNG and 250 KB as JPG, with the JPG showing visible ringing around every glyph.

The second is logos and line art. Vector content rasterized to a small bitmap should always be PNG (or SVG when possible). The flat fills compress to nothing under DEFLATE, and JPEG would smear the edges.

The third is anything with transparency. Baseline JPG has no alpha channel. If you need a logo to sit on an arbitrary background, PNG is the only option among traditional formats.

The fourth is any image that will be re-edited. PNG masters survive arbitrary save cycles. JPG masters degrade.

The fifth is technical, scientific, or medical imaging where the integrity of every pixel is part of the deliverable.

"Lossy compression is acceptable when the consumer is a human eye. It is malpractice when the consumer is a measurement instrument or a downstream algorithm." Donald Knuth, in correspondence about TeX font rasterization, paraphrased in Concrete Mathematics.

When JPG Wins Decisively

JPG is the correct choice for photographs published at a final resolution. A holiday photo, a product shot, a stock image, a hero banner: all of these should ship as JPG (or as a modern format like AVIF or WebP, with JPG as the fallback). The byte savings are not optional in a world where Largest Contentful Paint is a ranking signal.

JPG also wins for any large catalog of imagery where storage cost matters: e-commerce product galleries, real estate listings, archival scans of color-rich originals. A million product photos at 200 KB each is 200 GB. The same set as PNG would be 4 TB.

Color Depth and the Banding Problem

PNG supports 16 bits per channel; JPG supports 8. For ordinary web images this never matters. For deep gradients, sky photographs, scientific visualizations, and HDR content, 8 bits produce visible banding because there are only 256 luminance steps per channel. If your output medium can render more than 8 bits (a modern phone display can), and your gradient is smooth enough, you will see contour bands in the dark regions.

The mitigation in 8-bit pipelines is dithering. Floyd-Steinberg or blue noise dithering breaks up the banding by adding controlled noise. PNG can carry the dithered result without quality loss; JPG will partially undo the dither during quantization.

Metadata, Color Profiles, and EXIF

Both formats can carry color profiles and EXIF metadata, but with different conventions. JPG uses APP markers; APP0 is JFIF, APP1 is EXIF and XMP, APP2 is ICC profile. PNG uses typed chunks; iCCP holds the ICC profile, tEXt and iTXt hold textual metadata, eXIf (added in 2017) holds EXIF.

Strip metadata before publishing. Camera EXIF often contains GPS coordinates, device serial numbers, and software versions that you do not want to ship.

# Remove all metadata while preserving color profile
exiftool -all= -tagsFromFile @ -ICC_Profile photo.jpg

# Wipe everything including ICC
exiftool -all= -overwrite_original photo.jpg

# Inspect what is actually in the file
exiftool -a -G1 -s image.jpg
"Metadata is the part of a file format people ignore until it leaks something embarrassing. Strip it at the boundary of every system that publishes images." Bruce Schneier, Schneier on Security blog, on EXIF GPS leakage.

Progressive JPEG and Interlaced PNG

Both formats support progressive rendering with very different mechanisms. Progressive JPEG stores the DCT coefficients in multiple scans, low frequencies first, so the decoder can show a blurry preview that sharpens as more bytes arrive. Interlaced PNG uses Adam7, a seven-pass interleave that reveals the image at increasing spatial resolution.

Progressive JPEG is almost always smaller than baseline JPEG (a few percent) and renders better on slow connections. Use it. Adam7 PNG is roughly 25 percent larger than its non-interlaced sibling and offers little practical benefit on modern networks. Skip it.

Cross-Format Production Pipeline

A reasonable production rule in a CMS or image service:

  1. Accept input as PNG, TIFF, or RAW. These are the master.
  2. Generate JPG at quality 82 with mozjpeg for photo-content responsive variants.
  3. Generate PNG (optipng -o2) only for assets flagged as graphics or transparent.
  4. Generate AVIF or WebP as the modern primary; ship JPG or PNG as the fallback in a <picture> element.
  5. Store metadata-stripped, color-profile-preserved versions separately from originals.
# Minimal Make-driven pipeline
SRC := $(wildcard masters/*.png)
JPG := $(patsubst masters/%.png,public/%.jpg,$(SRC))

public/%.jpg: masters/%.png
	convert $< -strip -sampling-factor 4:2:0 -interlace JPEG -quality 82 $@
	jpegoptim --strip-all --max=82 $@

all: $(JPG)

Common Mistakes I Have Audited

Three patterns repeat in almost every team I have audited.

The first is exporting product photos as PNG because someone said PNG is higher quality. The catalog ships at four times the necessary bandwidth and Lighthouse penalizes the page.

The second is exporting screenshots as JPG to save bytes. The text becomes mushy, the user files a bug, and the team spends an hour debating whether the compression is acceptable. It is not. Screenshots ship as PNG (or WebP lossless).

The third is repeatedly editing and resaving JPGs in a content workflow. Each save loses a little more. By the fifth round of edits the image looks like it was photographed through a frosted window. Keep PNG masters.

Modern Successors

JPEG XL and AVIF are the formats that actually replace both JPG and PNG. JPEG XL supports lossy and lossless modes in one file, alpha, 16-bit color, and progressive decoding, and it lossless-transcodes existing JPG files at roughly 20 percent smaller. AVIF, based on AV1 intra coding, is roughly half the size of JPG at equivalent quality and is now supported by every shipping browser.

PNG is also evolving: APNG (animated PNG) is supported across browsers, and the Third Edition of ISO/IEC 15948 is in active development to add HDR and animation natively.

For deeper coverage of how content formats interact with measurement instruments and cognition, see the format psychology pieces at whats-your-iq.com, and for examples of image-heavy content publishing pipelines see the field-tested patterns at whennotesfly.com.

Practical Recommendations

If you remember nothing else, remember this: photographs ship as JPG (or AVIF), graphics ship as PNG. Quality 82 is the right JPG default for the open web. Always strip metadata at the boundary. Never resave a JPG you intend to ship through the same workflow twice. Keep PNG masters of anything you might edit again.

The format you choose is not a stylistic decision. It is a quantitative one with measurable consequences in bytes, in render time, and in the trust the user places in your site.

Sub-Formats and Variants Worth Knowing

JPEG and PNG each have variants that solve specific problems, and most developers do not know they exist.

JPEG-LS (ISO/IEC 14495) is a near-lossless variant of JPEG designed for medical imaging and continuous-tone images where every detail matters but file size still does. It uses a predictor and Golomb-Rice coding rather than DCT, achieving 30 to 40 percent smaller files than PNG on photographic content while remaining lossless or near-lossless. Most consumer toolchains do not include it; medical PACS systems do.

JPEG 2000 (ISO/IEC 15444) replaces DCT with the discrete wavelet transform, supports lossless and lossy modes in one bitstream, and is the format of choice in cinema (DCP), satellite imagery, and some medical workflows. It never gained web traction because the licensing was unclear in the early 2000s and the encoder was slow.

PNG with palette (PNG-8). A PNG with an indexed colormap of up to 256 colors. For graphics that fit within that palette (logos, icons, simple illustrations), PNG-8 is dramatically smaller than truecolor PNG-24 with no perceptual loss.

APNG (Animated PNG). A 2008 extension that turns PNG into a frame-sequence animation format with full alpha support. Every browser supports it; it is the right replacement for animated GIF in 2026.

# Convert an animated GIF to APNG with much smaller file size
ffmpeg -i loop.gif -plays 0 loop.png

# Encode JPEG 2000 from a TIFF (for archival workflows)
opj_compress -i scan.tif -o scan.jp2 -r 20

# Quantize a truecolor PNG to PNG-8 with dithering
pngquant --quality=70-90 --speed 1 logo.png -o logo-8.png

Performance Implications on the Web

Format choice has measurable Core Web Vitals impact. Lighthouse penalizes pages that ship oversized PNGs and rewards pages that serve modern formats with appropriate fallbacks. The mechanics that matter:

MetricJPG impactPNG impact
Largest Contentful PaintSmaller bytes, faster paintLarger bytes, slower paint
Cumulative Layout ShiftSame (with width/height attrs)Same (with width/height attrs)
Decode time on mobileHardware-acceleratedSoftware, slightly slower
CDN costLowerHigher
Image cache hit ratioSameSame
The serving pattern that consistently wins on Lighthouse: 
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="Hero" width="1920" height="1080" loading="lazy">
</picture>

This delivers AVIF to browsers that decode it, WebP to those that do not but support WebP, and JPG as the universal fallback. The browser picks the first format it understands. Bandwidth savings on the typical page are 30 to 60 percent.

  1. Wallace, Gregory K. "The JPEG Still Picture Compression Standard." Communications of the ACM, vol. 34, no. 4, April 1991, pp. 30 to 44. DOI: 10.1145/103085.103089.
  2. ISO/IEC 10918-1:1994. Information technology, Digital compression and coding of continuous-tone still images, Requirements and guidelines.
  3. ISO/IEC 15948:2003. Information technology, Computer graphics and image processing, Portable Network Graphics (PNG), Functional specification.
  4. Boutell, Thomas, ed. RFC 2083, PNG (Portable Network Graphics) Specification Version 1.0. Internet Engineering Task Force, March 1997.
  5. Deutsch, L. Peter. RFC 1951, DEFLATE Compressed Data Format Specification version 1.3. May 1996.
  6. Pennebaker, William B., and Joan L. Mitchell. JPEG: Still Image Data Compression Standard. Van Nostrand Reinhold, 1992.
  7. Salomon, David. Data Compression: The Complete Reference. 4th ed., Springer, 2007. ISBN 978-1-84628-602-5.
  8. Mozilla Corporation. mozjpeg encoder documentation. https://github.com/mozilla/mozjpeg