Three image formats carry the bulk of the visible web. JPG handles photography. PNG handles screenshots, UI, and anything that needs lossless reproduction. SVG handles logos, icons, and any image that originated as vector data. The three are not interchangeable; each solves a different problem and fails badly when applied to the wrong content. Picking correctly is one of the highest-leverage choices in front-end engineering, and one of the most consistently mishandled.

This guide is a working reference for when to use each format, with side-by-side benchmarks, production-ready code patterns, and explicit rules for the cases where the choice is non-obvious. The newer formats (WebP, AVIF, JPEG XL) extend the JPG and PNG categories rather than replacing them, and the picture element makes serving them straightforward.

The Single-Sentence Decision Rule

If the source is vector data, ship SVG. If the image needs lossless preservation or transparency, ship PNG. If the image is a photograph, ship JPG (or AVIF/WebP with JPG fallback).

The rest of this article explains why this rule holds and how to apply it cleanly.

What Each Format Actually Does

The three formats represent three different mental models of what an image is.

JPG (JPEG, ISO/IEC 10918). A lossy raster format designed for continuous-tone photographic content. Encoding works in the YCbCr color space with discrete cosine transform compression and chroma subsampling. The format trades pixel-exact reproduction for dramatically smaller file sizes on photographs. It does not support transparency.

PNG (ISO/IEC 15948). A lossless raster format designed to preserve every pixel exactly. Compression is DEFLATE-based, supplemented by per-row prediction filters that exploit spatial coherence. PNG supports 8 and 16 bits per channel, alpha transparency, and color profiles. It is universal across every browser and image library.

SVG (W3C Recommendation). A vector format based on XML. Images are described as paths, shapes, and text rather than as pixel grids. The browser rasterizes the SVG at display time, which means a single file looks crisp at any resolution. SVG supports CSS styling, animation, and accessibility features that raster formats cannot match.

Each format makes a specific bet about what the image is and how it will be displayed. JPG bets the image is a photograph. PNG bets the image is a precisely-defined pixel grid. SVG bets the image is a description that should be rendered fresh at the display resolution. Mismatched bets produce poor results.

"Choosing an image format is choosing a model for the image. The wrong model wastes bytes, hurts quality, or both. The right model is invisible." Nicolaas Matthijs, web standards engineer at the W3C

Side-by-Side Comparison

The following table summarizes the differences across the dimensions that matter for production choices.

PropertyJPGPNGSVG
CompressionLossyLosslessLossless (XML)
Best forPhotographsScreenshots, UILogos, icons, illustrations
File size (typical 300x300 logo)18 KB8 KB0.6 KB
File size (typical 1080p photo)240 KB2.1 MBnot applicable
Resolution-independentNoNoYes
Alpha transparencyNoYesYes
AnimationNoAPNG (limited)Yes (SMIL or CSS)
CSS stylingNoNoYes
Accessible (text via title/desc)EXIF onlymetadata onlyYes (native)
Browser supportUniversalUniversalUniversal
Color depth8-bit per channel8 or 16 bitsColor-managed RGB
Editable in browserNoNoYes (DOM)
The rows that drive most format decisions are the first three. Compression type, content fit, and file size for the actual image you have determine the right format more than any other property.

When SVG Is the Right Choice

SVG is the right format whenever the image originated as vector data. The list of typical SVG content:

  • Logos.
  • Icons.
  • Illustrations with hard edges (technical diagrams, infographics).
  • Charts and graphs.
  • Maps where coordinate-level precision matters.
  • Decorative elements that scale across viewport sizes.

The advantages compound. A single SVG file works at any resolution, which eliminates the need for srcset variants. SVGs are almost always smaller than the equivalent PNG. SVGs can be styled with CSS (changing color, animating transitions, supporting dark mode). And SVGs are accessible by default when authored with title and desc elements.

A production-grade SVG icon:

<svg xmlns="http://www.w3.org/2000/svg"
     viewBox="0 0 24 24" width="24" height="24"
     role="img" aria-labelledby="search-title">
  <title id="search-title">Search</title>
  <desc id="search-desc">A magnifying glass icon</desc>
  <path d="M10 2a8 8 0 1 0 5.3 14L21 22l1-1-6-6A8 8 0 0 0 10 2z"
        fill="currentColor" stroke="none" />
</svg>

Two production patterns deserve explicit mention. First, inline critical SVGs into the HTML rather than referencing them via img tags; this avoids a network roundtrip and lets CSS style the SVG. Second, run all SVGs through SVGO before deployment; the unoptimized SVG output of design tools often contains 50 to 80 percent removable cruft.

# SVGO with safe defaults
svgo --multipass \
     --pretty=false \
     --config='{"plugins":[
       "preset-default",
       {"name":"removeViewBox","active":false}
     ]}' \
     icons/*.svg

Sites with large icon inventories, including the visualization-heavy content at whats-your-iq.com and evolang.info, benefit from disciplined SVG pipelines because the byte savings compound across thousands of references.

When PNG Is the Right Choice

PNG is the right format whenever pixel-exact preservation matters and SVG is not viable. The canonical PNG content types:

  • Screenshots, including UI and code.
  • Diagrams that originated as raster.
  • Charts exported as raster.
  • Photographs that need pixel-exact preservation (rare, but real for some scientific and forensic use cases).
  • Any image that will be edited further and saved repeatedly.
  • Images with alpha transparency that cannot be expressed as SVG.

PNG's lossless compression means text and edges stay sharp. JPEG's DCT-based compression smears edges into halos that are visibly worse than a PNG of the same size for screenshot content. The size penalty for photographs is real but acceptable when fidelity is non-negotiable.

The two important production techniques for PNG:

# Lossless optimization with oxipng + Zopfli
oxipng --opt max --strip safe --zopfli screenshot.png

# Lossy quantization (still PNG, much smaller)
pngquant --quality 70-90 \
         --strip --speed 1 \
         --output screenshot.q.png screenshot.png

Quantized PNG is technically lossy but produces output that is visually indistinguishable from the source for most UI and illustration content while shrinking files by 60 to 80 percent. It is still a PNG and works in every browser.

"PNG is not a single format; it is a family of choices. Indexed-palette PNGs are tiny; truecolor PNGs are universally readable. Choose based on the content, not on the extension." Glenn Randers-Pehrson, lead author of the PNG specification

When JPG Is the Right Choice

JPG is the right format for photographic content delivered to humans. Continuous-tone images compress well under DCT and chroma subsampling because the human visual system is less sensitive to color detail than luminance detail.

Quality settings around 80 to 85 (using mozjpeg's quality scale) hit a near-optimal point for most content. Above 90, the file size grows without proportional perceptual improvement. Below 70, visible artifacts appear.

# Production-quality JPEG with mozjpeg
cjpeg -quality 82 \
      -progressive \
      -optimize \
      -dc-scan-opt 2 \
      -outfile photo.jpg photo.png

The progressive flag deserves attention. Progressive JPEGs render incrementally, which improves perceived load time on slow connections. Modern browsers handle progressive JPEGs efficiently; there is no longer a meaningful decode-cost penalty.

For modern web delivery, the picture element pattern serves AVIF and WebP variants alongside JPG, with JPG as the universal fallback:

<picture>
  <source type="image/avif" srcset="photo.avif" />
  <source type="image/webp" srcset="photo.webp" />
  <img src="photo.jpg" alt="Photograph description"
       width="1200" height="800" loading="lazy" />
</picture>

This pattern is the right default for any photograph on a modern site. AVIF saves 30 to 50 percent over JPG, WebP saves 25 to 35 percent, and JPG is the floor that always works.

The Cases Where the Choice Is Non-Obvious

Several categories of image have legitimate format ambiguity. The right approach for each:

Mixed content (text overlaid on a photo). The text component prefers PNG; the photo component prefers JPG. The pragmatic answer is usually JPG with the text rendered after compression as HTML/CSS, which keeps text crisp without paying the photographic-content PNG penalty.

Detailed illustrations with smooth gradients. Could be SVG, could be PNG, could be lossy WebP. Benchmark on the actual content. SVG wins for smaller illustrations; PNG or WebP wins for highly detailed work.

Charts and graphs. SVG is almost always the right answer. Modern chart libraries (D3, ECharts, Recharts) emit SVG natively, which means the chart is data-bound and accessible.

Animated content. GIF is wrong for new content. The right answers are SVG (for vector animation), animated WebP or AVIF (for short raster loops), or a video element with H.264 and AV1 sources (for longer or higher-quality content).

Hero images. Photograph: AVIF/WebP/JPG. Vector illustration: SVG. The format choice for a hero image directly affects Largest Contentful Paint, so optimization matters.

Content TypeGood ChoiceAcceptable AlternativeWrong Choice
LogoSVGPNGJPG
Photo of foodAVIF + JPG fallbackWebP + JPGPNG
Code screenshotPNG or lossless WebPquantized PNGJPG
Animated bannervideo elementanimated WebPGIF
Stat dashboardSVGPNGJPG
Marketing illustrationSVGPNGJPG
Camera-captured product photoAVIF + JPG fallbackWebP + JPGPNG
Map with labelsSVGPNGJPG

File Size in Practice

Benchmark numbers vary by content but the patterns are stable enough to plan against.

ImageJPG q=82PNG (lossless)PNG (quantized)SVGAVIF q=50
24x24 magnifier iconnot applicable0.4 KB0.3 KB0.6 KBnot applicable
200x60 wordmark logonot applicable4 KB2 KB1.2 KBnot applicable
1080p portrait photograph240 KB2.1 MBnot applicablenot applicable145 KB
1080p code screenshot180 KB (with halos)220 KB90 KBnot applicable110 KB
800x600 chart with 6 series90 KB (with halos)65 KB25 KB8 KB45 KB
1920x1080 product render320 KB2.8 MBnot applicablenot applicable195 KB
The "not applicable" entries reveal the structural answer. SVG does not apply to photographs; JPG does not apply to icons. Choosing the right format eliminates options that would have been bad anyway.

Production Patterns That Get Format Choice Right

Three patterns embed format discipline into a content pipeline so that individual contributors get the right format without thinking about it.

Build-time format generation. A static site generator or asset pipeline takes the source image, identifies its category (photo vs screenshot vs vector source), and produces the right derivatives automatically. This eliminates manual format choice for everyday content.

CDN-based format negotiation. The CDN serves AVIF, WebP, or JPG based on Accept headers without the author choosing. Cloudflare Polish, Akamai Image Manager, and Vercel image optimization all handle this.

Source-format discipline. Originals enter the system in the right canonical format: SVG for vector, PNG (or TIFF) for lossless raster, high-quality JPG for camera output. Conversion happens at well-defined pipeline stages, never silently in editing tools.

Sites running these patterns deliver consistent quality at scale. Sites without them ship a mix of GIFs that should be MP4s, JPGs that should be PNGs, and PNGs of photographs that bloat page weight. The pipeline discipline is what separates the two.

For broader image format strategy, the essential guide to choosing the right image format for web and the mastering image compression for web performance articles on this site cover related operational decisions. Sites with high-volume image inventories like the city guides at downundercafe.com demonstrate these patterns at scale.

Common Mistakes

The recurring mistakes in format choice are predictable and easy to fix once identified.

  1. PNGs of photographs. Massive files, no perceptual benefit. Convert to JPG (or AVIF) and ship the smaller file.
  2. JPGs of screenshots. Visible halos around text. Convert to PNG or lossless WebP.
  3. Raster icons that should be SVG. Pixelation on high-DPI displays, large file sizes. Re-export from the source as SVG.
  4. GIFs of anything. Use video element for motion, animated WebP for short loops.
  5. Stripping ICC profiles during conversion. Color shifts on color-managed displays. Preserve the profile.
  6. Forgetting alpha when converting JPG to PNG. Halos around image edges if the receiving template assumes transparency.

Each fix is mechanical once the diagnosis is correct. The bottleneck is identifying which images fall into which category, which is what build-time tooling and content-type-aware CDN pipelines solve.

A 2026 Default Recipe

For teams that want a working defaults set:

  • Logos and icons: SVG, optimized with SVGO, inlined in critical render path.
  • Screenshots and UI: PNG or lossless WebP via picture element.
  • Photographs: AVIF first, WebP second, JPG fallback via picture element.
  • Animation: video element with H.264 and AV1 sources, AVIF or WebP for short loops, never GIF.
  • Charts and visualizations: SVG, accessible, themed with CSS.
  • Always: width and height attributes to prevent layout shift, lazy loading on offscreen images, eager loading on the LCP candidate.

These defaults produce the smallest correct files for each content type, scale across viewport sizes, work with screen readers, and support theming. They are the same recommendations the major web performance benchmarks (Lighthouse, WebPageTest, the Web Almanac) converge on.

Edge Cases Worth Knowing

Five common edge cases challenge the basic decision rule and benefit from a deliberate answer.

Pixel art and retro illustrations. PNG with nearest-neighbor scaling is correct. JPEG smears the hard pixel boundaries; SVG cannot represent pixel-grid intent.

Print-bound assets. JPG with quality above 90 is acceptable for screen-resolution print. For print at native resolution, TIFF or PDF, not the formats discussed here, are the right answers.

Photographs intended for grayscale rendering. A grayscale JPEG is dramatically smaller than a color JPEG of the same content. Strip color where it is not used.

Banner overlays with text. Render text in HTML/CSS over a smaller hero image. Compositing text into the image forces lossless formats and inflates page weight.

User-uploaded content of unknown provenance. Default to converting to a known canonical format on the server before storing. Do not trust client-supplied formats for downstream processing.

Each edge case admits a clear answer once the underlying constraint is named. The decision rule is the starting point, not the destination.

Closing Note

Format choice is one of the few engineering decisions where the right defaults are well-known, the cost of mistakes is measurable, and the discipline required is small. The teams that ship the right format every time do so because their pipeline picks the format from the source, not because individual contributors think hard about each upload. Build that pipeline once and the rest takes care of itself.

References

  1. ITU-T Recommendation T.81, JPEG specification, 1992. https://www.itu.int/rec/T-REC-T.81
  2. ISO/IEC 15948:2004, Portable Network Graphics (PNG). https://www.iso.org/standard/29581.html
  3. W3C, Scalable Vector Graphics (SVG) 2 Recommendation. https://www.w3.org/TR/SVG2/
  4. AOMedia, AV1 Image File Format (AVIF) 1.1.0. https://aomediacodec.github.io/av1-avif/
  5. Google Developers, WebP Compression Study. https://developers.google.com/speed/webp/docs/webp_study
  6. HTTP Archive, Web Almanac 2024, Media chapter. https://almanac.httparchive.org/en/2024/media
  7. W3C, Responsive Images Community Group, Picture element specification. https://html.spec.whatwg.org/multipage/embedded-content.html#the-picture-element
  8. Wang, Z. and Bovik, A. C. Image quality assessment from error visibility to structural similarity. IEEE Transactions on Image Processing, 13(4), 2004. https://doi.org/10.1109/TIP.2003.819861