There are three ways to put icons on a page: an icon font, an SVG sprite, or inline SVG. All three draw the same picture, so the choice looks like a matter of preference. In practice it decides three things — how many colours an icon may have, what assistive technology announces, and how many icons actually travel to the visitor.
What actually differs
The names sound similar; the work the browser does is not.
An icon font packs the icons into a typeface as glyphs, so a particular character code produces a particular drawing. Size comes from font-size and colour from color, which makes it remarkably easy to work with.
An SVG sprite collects the shapes into one file and the document pulls out what it needs with <use>. One file gets cached, and every icon stays a real vector shape.
Inline SVG writes the shape straight into the document. No extra request, and CSS can address every part of the drawing — at the cost of repeating the markup wherever the same icon appears.
First criterion: how many colours?
This one question eliminates most of the field. An icon font is a letter, so it is always exactly one colour. Two-tone icons, icons where only part of the drawing changes on hover, icons whose stroke and fill differ — none of them are possible by construction.
The font does have one real advantage in return. Because the colour is inherited text colour, an icon dropped into a button simply becomes the button’s text colour. On links, buttons and badges, where the colour is already decided, there is almost nothing to wire up.
SVG can have the same convenience. Set fill to currentColor and the shape inherits text colour, leaving custom properties for the rare places that need a second tone. If there is any chance you will need more than one colour, start with SVG — moving from a font to SVG later means touching every place an icon appears.
Second criterion: what does a screen reader hear?
To a screen reader an icon font is text. The characters usually sit in a private-use range, so the reader either announces a meaningless symbol or says nothing at all. Neither helps anybody.
Which is why the rule is the same whichever approach you choose: hide the icon from assistive technology and supply the meaning as words.
<!-- A visible label is present, so the icon is decoration -->
<button class="btn">
<svg class="icon" aria-hidden="true" focusable="false"><use href="#icon-download"/></svg>
Download
</button>
<!-- Icon-only button: give it a name -->
<button class="btn btn--icon" aria-label="Search">
<svg class="icon" aria-hidden="true" focusable="false"><use href="#icon-search"/></svg>
</button>Icon fonts carry one further condition. When a reader turns on a setting that forces their own typeface — a genuinely used accessibility feature — the icon font is substituted too, leaving stray characters or empty boxes where the icons were. A button whose only meaning was its icon loses its identity at that moment. Keeping a text label alongside handles this case as well.
Third criterion: how many actually ship?
This is where the performance difference lives. An icon font is usually the entire set in one file. Use ten icons or twenty and the visitor still downloads a typeface containing hundreds. You can subset it at build time, but by then you are doing roughly the work an SVG sprite would have asked for anyway.
A sprite can contain only what you use, and the single file caches well. Inline SVG makes no request at all but lengthens the document when the same shape repeats — though repeated strings compress well, so on a page with a handful of icons that cost stays small.
Whichever you choose
What outlasts the choice is consistency. Fix the icon grid — commonly 24 or 20 — and the stroke weight, or the moment you mix icons from different sources some will look heavier than others at identical sizes. The mismatch becomes visible as soon as a screen holds more than about five icons.
Icon size and colour are also worth expressing as tokens. Bind size to something like --icon-size and colour to inherited text colour, and neither dark mode nor a rebrand will send you back through the icon set on its own.
Designing that token structure from the start is covered in the design tokens series, and how theme and plugin choices affect asset weight lives in the themes and plugins archive. If you would like to know what a live site is actually downloading, that diagnostic is part of our optimization program.