How you ship icons affects performance, accessibility and how easily a designer can change them. The landscape has changed enough that old advice is actively harmful.

Icon Fonts: Mostly Legacy

Icons packaged as glyphs in a font file, rendered via CSS pseudo-elements.

Why they were popular: one HTTP request, styleable with colour and font-size, scalable.

Why they've fallen out of favour:

  • Accessibility problems: screen readers may announce the private-use characters as gibberish, and font substitution can render an unrelated character if the font fails to load.
  • Single colour only (barring hacks with stacked glyphs).
  • Blocking behaviour: a failed or slow font means missing or wrongly-substituted icons.
  • Whole-file cost: you ship hundreds of icons to use twelve, unless you subset carefully.
  • Rendering: icons are anti-aliased as text, which can look slightly off at certain sizes.

Keep them only in legacy codebases where migration isn't worth the churn.

CSS Sprites: Narrow but Alive

One raster image containing many icons, positioned with background-position.

Still reasonable when: your icons are genuinely raster (photographic, complex gradients, multi-colour illustrations), or you support environments where SVG is restricted.

Drawbacks: fixed resolution needing a 2× variant for high-DPI screens, awkward maintenance (every change re-renders the sheet and shifts coordinates), no per-icon colour changes, and all icons download even if one is used.

Note that HTTP/2 and HTTP/3 removed the original motivation — request count is no longer expensive — so sprites are now a niche choice rather than a performance technique.

SVG: The Default

Vector icons, either inline in the markup or referenced from an SVG sprite via use.

Advantages:

  • Crisp at any size and DPI, no 2× variants.
  • Styleable with CSS — colour via currentColor, hover states, individual parts, even animation.
  • Accessible: a title element or aria-label makes an icon's meaning explicit, and aria-hidden hides purely decorative ones.
  • Tiny when optimized: most UI icons compress to a few hundred bytes.
  • Multi-colour and gradient-capable.

Trade-offs:

  • Inline SVG isn't cached separately — it's part of the HTML, so repeated icons across pages are re-sent. Fine for a dozen icons; consider an SVG sprite file or a component that reuses symbols if you have hundreds.
  • Markup bloat if you paste unoptimized editor exports. Run icons through an optimizer to strip editor metadata, hidden layers and excessive precision.
  • Sanitize user-supplied SVG. SVG can contain script; never inline untrusted files.

Practical Recommendation

Use inline SVG for interface icons, an SVG sprite when the same icons repeat across many pages, and raster sprites only for genuinely photographic assets. Whichever you choose, decide per icon whether it is meaningful (needs an accessible name) or decorative (should be hidden from assistive tech) — that single habit fixes most icon accessibility problems.