SVG Illustrations
Hero art, feature rows, empty states and spot illustrations — website art that weighs what a paragraph weighs. How you embed it decides whether CSS can theme it, whether a screen reader announces it, and whether it caches.
the same hero illustration
Indicative figures for one flat illustration. The ratio holds for flat art; it inverts for photographic sources.
Four ways in
One question settles it nearly every time: does anything outside the file need to reach inside it? Styling, theming, animation and per-element targeting all require inline. Nothing else does.
Small, above the fold, or anything that has to restyle or move.
You gain
Page CSS reaches every node. currentColor, CSS variables, hover states, animation, per-element ids to target. No extra request.
You give up
The markup lives in the HTML, so it is re-sent on every page load rather than cached separately, and every path becomes a DOM element.
Large art, anything repeated across pages, anything static.
You gain
Cached like any other image, kept out of the DOM entirely, and alt text works the way screen readers expect. Lazy-loadable with one attribute.
You give up
Isolated from the page: external CSS and JavaScript cannot reach inside it, so currentColor and theme variables do nothing.
Dividers, textures, ornamental flourishes.
You gain
Out of the document altogether, which is right for decoration. Can be swapped per breakpoint or per theme in the stylesheet.
You give up
Invisible to assistive technology — correct for ornament, wrong for anything carrying meaning. Same styling isolation as an img.
Effectively legacy — reach for inline or img instead.
You gain
Loads as its own document, so scripts and styles inside the file run.
You give up
Awkward fallbacks, an extra browsing context, and accessibility that behaves differently across screen readers. Rarely the right answer now.
Budgets by placement
Not rules — starting points. The path count matters as much as the byte count when the illustration is inlined, because every path is a DOM node.
| Placement | Byte budget | Paths | Notes |
|---|---|---|---|
| Hero illustration | 15 – 40 KB | 60 – 200 | Above the fold and in the LCP path. Inline it so it paints with the HTML, and keep the palette to four or five values. |
| Feature row art | 3 – 10 KB | 15 – 50 | Three or four of these appear together, so the budget is per item multiplied by the row. Share one style across all of them. |
| Empty state | 4 – 12 KB | 20 – 60 | Rendered rarely and never on first paint. Lazy-load it; there is no reason for it to be in the initial bundle. |
| Spot icon | under 2 KB | under 15 | Small enough to inline anywhere. Use currentColor so it inherits text colour with no extra work. |
| Background pattern | under 2 KB | one tile | Define the tile once as a pattern and repeat it. A repeated tile is one definition however large the area. |
| Decorative divider | under 1 KB | 1 – 5 | Purely ornamental, so it belongs in CSS as a background image and out of the document entirely. |
Why vector on the web
One file covers 1×, 2× and 3× displays. No @2x variant, no srcset, no decision about which raster size to ship.
Fills are attributes, so a CSS variable or a currentColor reference recolours the whole illustration for dark mode without a second asset.
Under a few kilobytes an illustration can live in the HTML and cost zero requests — which matters most for the one image above the fold.
A stroke can draw itself, a group can drift, a colour can transition. All of it in the same file, with no video and no library.
A title element gives the illustration a name; aria-hidden removes it from the tree when it is decoration. Both are one attribute.
It is text. Reviewers can see that a colour changed rather than staring at two binaries and taking your word for it.
The pattern
Drop the width and height, keep the viewBox, reference CSS variables in the fills, and give the illustration a title if it carries meaning. That is the whole technique.
How viewBox scaling works
<svg
viewBox="0 0 800 600"
role="img"
aria-labelledby="hero-title"
class="w-full h-auto">
<title id="hero-title">
Two people assembling a chart
</title>
<g id="figures" fill="var(--brand)">
<path d="M120 480 C 160 380, …"/>
</g>
<g id="chart" fill="currentColor">
<rect x="480" y="220" …/>
</g>
</svg>The other side
None of these is a reason to avoid vector for interface art. They are the cases where it is the wrong tool, and knowing them is most of the skill.
An inlined illustration with 900 paths adds 900 DOM elements for layout and paint to walk. This, not file size, is what makes a heavy SVG feel slow.
Trace a photo and you get thousands of paths that are larger and worse-looking than the JPEG you started with. Flat and geometric artwork is where the maths favours vector.
Live <text> renders in whatever font is available. Outline the letterforms unless you control the font everywhere the file will be seen.
SVG can carry script, so an uploaded file from a stranger is a real attack surface. Sanitise anything user-supplied before you inline it.
Filters, blend modes and complex masks vary between engines. Ordinary shapes are consistent; the exotic features are worth checking.
A Figma or Illustrator export carries frames, transforms and metadata you do not need. Untouched, it can be several times the size it should be.
And one thing we are not: a library. Every illustration here starts from a prompt, so if you want something ready-made and free, unDraw, DrawKit, Lukasz Adam, Icons8 and Flowbite are the sets most projects reach for first. Generation earns its place when you need something specific, or a matching set nobody else is shipping.
Questions