skip to content

Why did icon fonts fall out of favour for delivering a design system's icons, and what do teams use instead?

level: middleimportance: should knowfreq 34%

answer

  1. icons pretending to be text
  2. font fails or user overrides it
  3. odd characters read aloud
  4. one color, whole set downloaded
  5. vectors as components or sprites

basics

~20 s

Icon fonts draw icons as text, so they break when the font fails or users override fonts, confuse assistive technology, align like text, carry one color and ship every glyph. Vector icons, as components or sprites, avoid this.

solid answer

~40 s

An icon font maps each icon to a character, so the icon is text. That was attractive — one cached download, colored and sized like text — but it fails in ways vectors do not. If the font is blocked, slow or replaced by a user's readability font, icons become empty boxes or stray letters. Assistive technology may announce nothing, an odd character, or the ligature word behind the glyph. Glyphs sit on text baselines and get text anti-aliasing, so alignment is fiddly and small sizes blur. Each glyph is practically one color, and the whole set downloads unless someone subsets it. Teams now ship **vector icons**: per-icon components that a build can drop when unused, a vector sprite referenced by id, and each native platform's own vector asset format.

go deeper

for a junior

Recall that an icon font draws icons as text characters, and name two ways that breaks: the font failing or being overridden, and odd screen reader output.

for a middle

Explain each failure's cause — text rendering, font replacement, character semantics, whole-set download — and which vector delivery keeps the old advantages.

for a senior

Show how you would migrate a shipping app from an icon font to vectors behind the existing icon component, including visual comparison for shifted baselines.

for a principal

Discuss when keeping an icon font is a reasonable local choice and why a shared design system should still default to vectors across every consuming app.

## How an icon font works, and why it was popular An **icon font** is a font file whose glyphs are icons instead of letters. Each icon is mapped to a character — usually a code point in Unicode's private-use area, or a **ligature** where typing a word such as “shuffle” renders the shuffle icon. The interface then shows an icon by placing that character in text styled with the icon font. For years this was the pragmatic choice. It delivered the whole set in **one cached download**, icons took the **text color** and **text size** automatically, and it worked in environments where vector graphics support was poor. A music-streaming app could draw play, pause, shuffle and repeat in any color by changing the text color of the button. ## Where it breaks | Problem | Cause | Who is hurt | |---|---|---| | Boxes or stray letters instead of icons | Font blocked, slow, or failed to load | Anyone on a poor network or locked-down device | | Icons vanish or turn into letters | User forces a readable font for all text | People with dyslexia or low vision who override fonts | | Odd or doubled announcements | The glyph is a character or a ligature word | Screen reader users | | Blurry, misaligned glyphs | Rendered with text anti-aliasing on text baselines | Everyone, most visibly at small sizes | | One color per glyph | Font glyphs are practically monochrome | Designers needing two-tone icons | | Every icon downloaded | The font carries the whole set | Users on slow or metered connections | ## The accessibility pitfalls in detail - **User font overrides.** Some people set their device or reading tools to replace every font with one they can read. An icon font is a font, so it gets replaced too, and the play button becomes a letter or a box. Vector icons are not text, so the override leaves them alone. - **What gets announced.** Because the icon is a character, assistive technology may say nothing, announce an unpronounceable character, or read the ligature word — “skip next filled” — sometimes run together with the button's real label. Hiding the glyph and labelling the control fixes the announcement, but the fix has to be applied at every use. - **Text-spacing and text-size changes** apply to the icon as if it were a word, which can shift or clip it inside tight controls. None of these are problems with icons as such; they come from **delivering icons as text**. ## What replaced it The common replacements all deliver icons as **vector graphics**: 1. **Per-icon components or modules.** Each icon is its own importable unit. A build can drop the ones an app never references, and each icon can be colored, sized and labelled through the same component contract. 2. **A vector sprite.** One file holds every icon definition, and each use references a definition by id. One cached request, shared definitions, no font behaviour. 3. **Per-platform vector assets.** Native mobile apps ship icons in each platform's own vector asset format, generated from the same source, with raster fallbacks only where a platform needs them. These keep what made fonts attractive — single-color icons can still take the surrounding text color, and a sprite still caches as one file — while dropping the text-rendering baggage. ## When an icon font is still defensible It is not a bug in every case. A small internal tool with a handful of icons, a platform where vector rendering is unavailable, or a legacy product mid-migration can reasonably keep one — provided the glyphs are hidden from assistive technology, the controls carry real names, and the font is subset to the icons in use. The argument against icon fonts is about **defaults for a shared design system**, where the failure modes multiply across every consuming app. ## Migrating a music app off an icon font 1. Inventory which glyphs are actually used, and where. 2. Generate vector equivalents from the same source drawings, at the same visual size. 3. Swap uses behind the existing icon component, so product code does not change. 4. Compare old and new renderings side by side, since baselines and optical size shift. 5. Remove the font once nothing references it.

  • Why does a user's font override break an icon font but not vector icons?
    An override replaces the font used for text. Icon-font icons are text, so the replacement font draws its own character — a letter or an empty box — where the icon was. Vector icons are graphics, not characters, so a font override never touches them. That is why a user who needs a readable font can lose every control's icon with a font-based set.
  • If a team must keep an icon font for now, how do they limit the damage?
    Subset the font to the glyphs in use, hide every glyph from assistive technology and give each control a real accessible name, avoid ligature words that could be read aloud, and plan the move to vectors behind the existing icon component so product code does not change when the delivery format does.

An icon font is like printing road signs as letters in a special typeface: the moment a reader swaps to a typeface they can read, every sign turns into gibberish.

saying these in an interview costs you the question

  • Icon fonts are immune to users who override fonts for readability.
  • Screen readers skip icon-font glyphs, so no handling is needed.
  • Icon fonts render more crisply than vector icons at small sizes.
  • The only drawback of icon fonts is the size of the font file.
  • Moving to vector icons means losing icons that follow text color.