SVG

SVG (Scalable Vector Graphics) is an XML-based vector image format. Instead of storing pixels, SVG stores instructions: “draw a circle of radius 50 at (100, 100), fill blue.” The browser rasterises at display time, so the same file looks crisp at any size from 16×16 to a 4K billboard.

Properties:

• Resolution-independent — same file for retina and standard displays.
• Tiny file sizes for simple shapes — a typical icon is 500 bytes to 5 KB. Beats every raster format on size for the same content.
• Editable as text — open in any editor, tweak the path data, save. No proprietary tooling required.
• CSS-styleable — fill, stroke, transform can come from external CSS.
• Animatable via CSS transitions and SMIL (though SMIL is being deprecated in favour of CSS + WAAPI).

Where SVG wins: logos, icons, illustrations, diagrams, data visualisations. Where it loses: photographs (no efficient way to represent millions of subtly-different pixels as vectors), complex gradients (file size balloons), 3D rendering (use canvas/WebGL).

Inline SVG (embedded in HTML) is the modern best practice for icons — no separate request, CSS-stylable, accessible via aria-label. External SVG (in a separate file) is fine for less critical assets.

The XSS attack surface nobody warns you about: SVG is XML and can contain <script> tags. An SVG uploaded to a forum, profile photo, or CMS becomes an arbitrary-code-execution vector if served with Content-Type: image/svg+xml from the same origin as the application. The mitigation is to sanitise user-uploaded SVGs (DOMPurify works) or serve them from a sandbox origin (img.example.com instead of example.com). Some hosts simply rasterise user SVGs to PNG on upload to remove the risk entirely.

Optimising SVG file size: SVGO is the standard command-line tool — runs ~40 plugins that strip metadata, simplify paths, merge transforms, and round numeric precision. Typical savings on Sketch/Figma exports are 50-80%, occasionally 95%+ for designs heavy with hidden layers and editor metadata. The compressed-on-disk SVG also gzip-compresses well (text content), so a 5 KB SVG often ends up under 1 KB on the wire. Reference: W3C — Scalable Vector Graphics (SVG) 2.

Worked example

A circular “X” close-button icon in SVG: <svg viewBox="0 0 24 24" width="24" height="24"><path d="M6 6l12 12M6 18L18 6" stroke="currentColor" stroke-width="2" stroke-linecap="round"/></svg> — that’s ~150 bytes uncompressed, ~80 bytes gzipped, and renders identically at 16 px, 24 px, 48 px, or as a 2-metre vinyl decal. The equivalent PNG at 1x is ~400 bytes; at 2x retina is ~1 KB; at 3x is ~1.8 KB; each separate file. The SVG’s currentColor attribute lets a single icon inherit text colour for hover states without producing two image files. Now consider an SVG with a complex gradient mesh and 5,000 path nodes (a detailed illustration exported from Illustrator): the file balloons to ~400 KB, and rasterising it at draw time costs measurable CPU per frame. At that point a 25 KB WebP is the better choice — vector wins for simple geometry, raster wins for complexity.

When and why it matters

The right format choice changes page weight and rendering performance by orders of magnitude. Use SVG for: logos (resolution-independent across breakpoints), monochromatic icons (sprite or inline), simple charts and infographics (D3 produces SVG), and any image that needs to be styled by CSS (theme-aware icons). Use raster (PNG/WebP/AVIF) for: photographs, screenshots, gradients with many colour stops, and any image with more visual complexity than a designer is willing to express as path commands. The sleeper benefit of SVG is accessibility: a well-marked-up SVG with <title> and <desc> elements is screen-reader-friendly in a way no raster image can be without separate alt text. Reference: MDN — SVG.