WEBPery

SVG

.svg

W3C vector graphics format from 2001. Resolution-independent and tiny for simple shapes; the standard choice for logos.

vectorlosslessTransparencyAnimation99% browser support

What SVG actually is

SVG (Scalable Vector Graphics) is a vector image format defined by XML. Unlike PNG, JPEG, WebP, or AVIF — all of which store a fixed grid of pixels — an SVG file describes geometric shapes, paths, gradients, text, and filters as mathematical instructions. The browser (or any SVG renderer) rasterises those instructions to pixels at whatever resolution the display needs.

This single property — resolution independence — is SVG's defining advantage. A 1 KB SVG icon looks identical at 16 pixels and at 1600 pixels. A 1 KB PNG icon looks correct at one size and progressively worse at every other.

SVG was developed by the W3C beginning in 1999. The first stable specification (SVG 1.0) was published in 2001. SVG 1.1 followed in 2003 and has been the practical baseline for most of the format's life. SVG 2 was published in 2018 and adds modern capabilities but is implemented inconsistently across renderers.

Why SVG is in a different category

Most image-format comparisons compare PNG, JPEG, WebP, AVIF — all raster formats. They differ in compression algorithms and feature sets but share the fundamental model: a grid of pixels.

SVG is different. It describes shapes, not pixels. This means:

  • Resolution independent. An SVG renders crisply at any size or pixel density. No need for @2x or @3x variants for retina displays.
  • Tiny for the right content. A simple logo can be 500 bytes as SVG vs 5 KB as the equivalent PNG.
  • Animatable. SVG supports declarative animation through SMIL and CSS, plus programmatic animation through JavaScript.
  • Inspectable and editable. SVG is text. You can open it in any editor, see the shapes, and modify them.
  • Stylable with CSS. SVG elements can be coloured, sized, and animated by external CSS rules.
  • Accessible. Text within SVG is selectable, searchable, and screen-reader-readable.

These are properties no raster format can match. For content that's natively vector — logos, icons, line art, diagrams, charts — SVG is structurally the right choice.

The flip side: SVG is wrong for content that's natively raster. Photographs are not made of geometric primitives. Encoding a photograph as SVG is technically possible (by tracing it to many small filled paths) but produces files dramatically larger than even uncompressed PNG.

Structure

An SVG file is XML. A minimal example:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <circle cx="50" cy="50" r="40" fill="#3b82f6" />
  <text x="50" y="55" font-size="20" text-anchor="middle" fill="white">SVG</text>
</svg>

The viewBox attribute defines the coordinate system. All coordinates and dimensions inside the SVG are relative to that coordinate space, which the browser scales to whatever rendered size the SVG occupies.

Common element types:

  • <rect>, <circle>, <ellipse>, <line>, <polyline>, <polygon> — geometric primitives.
  • <path> — arbitrary shapes defined by a "d" attribute containing move/line/curve commands. The most powerful element; most complex SVGs are built primarily from paths.
  • <text> — text rendered as text (selectable, searchable).
  • <g> — group element, used to apply transforms or styles to multiple elements.
  • <defs>, <linearGradient>, <radialGradient>, <pattern> — reusable definitions for fills.
  • <filter>, <feGaussianBlur>, <feColorMatrix> — image filter effects.
  • <use> — references and reuses a defined element. Used for icon systems.

File size

SVG file size depends on shape complexity, not on rendered pixel dimensions. A logo with 10 path elements is 1–2 KB at any rendered size. A logo with 1000 path elements is 50–100 KB at any rendered size.

For most logos and icons, SVG is dramatically smaller than the raster equivalents:

  • A typical company logo: 500 bytes – 2 KB as SVG, 4–8 KB as optimised PNG, 3–6 KB as lossless WebP.
  • A typical UI icon: 200–500 bytes as SVG, 1–2 KB as PNG, 800 bytes – 1.5 KB as lossless WebP.

For highly detailed illustrations with hundreds of paths, SVG can grow large. At that point the comparison flips: a heavily detailed illustration encoded as SVG may be 50 KB; the same illustration as lossy WebP at q=85 may be 25 KB. The decision becomes per-asset.

Optimisation

Raw SVG output from design tools (Illustrator, Sketch, Figma) often contains substantial overhead: editor-specific metadata, redundant decimal precision, unused gradients, hidden layers. Standard optimisation removes the bloat without changing the visual result.

The standard tool is svgo (SVG Optimizer):

svgo input.svg -o output.svg

svgo runs a configurable set of plugins that:

  • Remove editor metadata (Illustrator XML, Sketch comments).
  • Collapse redundant path commands.
  • Round coordinates to fewer decimal places.
  • Merge consecutive transforms.
  • Remove default attribute values.
  • Convert colours to shorter hex codes.

Typical reduction: 30–60% off raw Illustrator output, often without any visible change.

For SVGs used inline in HTML (embedded directly rather than referenced as files), additional cleanup matters:

  • Remove xmlns attributes (browsers don't need them in HTML5).
  • Remove <defs> for definitions used only once.
  • Inline single-use gradients.

Browser support

SVG support is universal. Every browser that supports CSS supports SVG. The only browser still in common use without SVG support is Internet Explorer 8 and earlier, which is below 0.1% of global traffic.

Where browser support varies is in which features of SVG are supported:

  • SVG 1.1 baseline — universal.
  • SVG 2 features (some new path commands, some new colour syntax) — inconsistent.
  • SMIL animations — supported in Firefox and Safari, deprecated then unrelocated in Chrome. Use CSS animations instead for cross-browser reliability.
  • CSS filters on SVG — universal.
  • SVG <filter> elements — universal but expensive to render; profile before relying on them for animations.

Rendering approaches

There are several ways to put SVG on a page, with meaningfully different trade-offs:

Inline SVG

<svg viewBox="0 0 24 24" width="24" height="24" fill="currentColor">
  <path d="..." />
</svg>

Pros: stylable with CSS (currentColor inherits text colour), no extra HTTP request, smallest payload.

Cons: each occurrence repeats the SVG markup. For an icon used 50 times on a page, this is wasteful.

<img> tag

<img src="/icons/logo.svg" alt="..." width="240" height="80" />

Pros: cacheable, simple. Works in CSS background-image too.

Cons: cannot be styled by parent CSS (the SVG is in a separate document context). External resources referenced by the SVG (e.g., other SVGs via <use>) won't load.

<svg><use href="..."> (icon system)

<svg width="24" height="24">
  <use href="/icons.svg#chevron-right" />
</svg>

A sprite file (/icons.svg) contains all icons defined inside <symbol> elements; each usage references one by ID. Pros: cacheable, stylable. The standard pattern for icon systems.

CSS background-image

.icon { background-image: url("/icons/logo.svg"); }

Pros: simple for decorative elements.

Cons: cannot be styled (currentColor doesn't work). Cannot be selected. Inaccessible to screen readers.

SVG vs raster: when to choose which

Content typeChoice
Brand logoSVG. Resolution-independent, tiny.
App / UI iconSVG. Stylable, scalable.
Line art / illustrationSVG for simple, raster for complex.
Chart, graph, infographicSVG. Animatable, accessible text.
DiagramSVG. Resolution-independent.
PhotographRaster. Always.
ScreenshotRaster. Use PNG or lossless WebP.
Complex illustrationDepends. Compare file sizes both ways.
Hand-drawn artRaster if scanned, SVG if traced.
Map (geographic)SVG if interactive, raster if static.

The decision is structural: is the content built from shapes, or from pixels? If shapes, SVG. If pixels, raster.

Accessibility

SVG is the most accessible image format. Text within an SVG is real text — readable by screen readers, selectable by users, searchable by browser find functions. Complex SVGs can use ARIA attributes and <title> and <desc> elements to provide context:

<svg viewBox="0 0 100 100" role="img" aria-labelledby="chart-title chart-desc">
  <title id="chart-title">Quarterly revenue chart</title>
  <desc id="chart-desc">Bar chart showing revenue growth from Q1 to Q4 2025</desc>
  <!-- chart elements -->
</svg>

For decorative SVGs, use role="img" and aria-label="" (or aria-hidden="true" to hide entirely).

When SVG is not the answer

Despite its strengths, SVG is the wrong choice for:

  • Photographic content. Even tracing photos into SVG paths produces dramatically larger files than raster equivalents.
  • Heavily detailed content where every pixel matters. A 5000-shape illustration is often better as a high-quality raster.
  • Cross-platform pixel-perfect rendering. SVG rendering differs subtly across renderers; for absolute pixel-perfect consistency (icon font rendering, OS clipboard), raster wins.
  • Distribution to systems that don't render SVG. Some older PDF viewers, some legacy email clients, some embedded device firmware.

Implementation guidance

For a typical site, SVG covers:

  • All icons (UI, decorative, brand).
  • Logos in all sizes.
  • Simple illustrations and diagrams.
  • Charts and data visualisations.

For complex illustrations and any photographic content, ship raster (WebP for browser delivery, PNG or JPEG for distribution beyond the browser). See WebP Optimisation.

Further reading