The Font Substitution Rate for a Typical Web to Figma Import

You import a page into Figma and a banner says three fonts were substituted. Normal, or did something go wrong? Based on 2025 web wide font data, the honest answer depends almost entirely on one thing: whether the page's fonts come from Google Fonts or from a self hosted file. A smaller set of format and platform details decides the rest.

Google Fonts make up roughly half of all font usage on the web, and Figma can fetch any Google Font on demand, so those text layers typically import with the family intact. Substitution clusters in a narrower pool instead: self hosted, non Google typefaces, variable fonts missing a style, and icon fonts. What follows: the numbers, why Google Fonts mostly survive an import, which fonts actually get swapped, and how to read an import report once it happens.

The numbers behind font substitution

The clearest public dataset here comes from the HTTP Archive's 2025 Web Almanac, which crawls the font requests and CSS of millions of live pages. As of that crawl, 88% of pages use at least one web font, up slightly from 87% in 2024. The remaining 12% rely on system fonts only, where substitution never comes up. There's no custom font to resolve in the first place.

Among pages that do use web fonts, the hosting split matters more than the headline number. 72% self host at least one font file, 36% self host exclusively with no third party service at all, and another 36% mix self hosting with Google Fonts. Only 13% rely on Google Fonts exclusively. Overall, Google Fonts appear on 54% of desktop pages and 47% of mobile pages, whether alone or alongside another source.

Put plainly: the 36% of pages that self host exclusively, plus the self hosted half of the 36% hybrid group, is roughly where a typical import's substitutions come from. The Google Fonts slice is close to a non issue.

This is a recent development, not a constant. Custom web fonts were in the low single digits when the HTTP Archive first tracked them in 2011, passed half of all sites by 2015, and reached roughly 75% adoption by 2020 before climbing to the 87% and 88% seen in 2024 and 2025. As adoption climbed, so did the odds that any page you import carries at least one font Figma has to resolve, one way or another. A decade ago the substitution question barely applied. Today it applies to almost every import.

Why Google Fonts practically never get substituted

Figma's own missing font dialog always lists Google Fonts as available, because Figma fetches them on demand rather than depending on what's already installed on your machine. A font that resolves to a Google Font doesn't need a local install, a license, or any extra step. It just works.

A page built on Roboto, Open Sans, or Poppins, the three most common named text fonts in the 2025 crawl after the Font Awesome icon font, usually imports with the family intact and no entry in the substitution report. Import a page built with a popular framework's default typography, and there's a decent chance you won't see a single font substitution.

Take a typical marketing landing page: a heading set in Poppins, body copy in Open Sans, and a handful of Font Awesome icons in the footer. Two of those three families resolve against Google Fonts without any local install, so the import report will likely flag only the icon font, if anything. Swap the body copy for a paid, self hosted typeface from a type foundry, and the picture changes completely. Now the import depends on whether you happen to have that exact family installed locally, in a format Figma can read.

The self hosted pool that triggers Inter

Self hosted fonts are a different story, and two technical details explain most of why.

Format gap: Figma reads TTF and OTF, not the WOFF2 most sites ship

65% of font requests on the web are served as WOFF2, with 16% WOFF 1.0 and 7% TrueType. But Figma's local font install only reads TTF and OTF files. A self hosted WOFF2 file, even one you've fully licensed, substitutes on import unless that same family is also installed on your machine in a format Figma can see. Having the right font name isn't enough. You need the right file format, installed locally, before Figma opens the page.

Variable fonts can substitute just one style

39.4% of desktop pages and 41.3% of mobile pages now use variable fonts, up from roughly a third in 2024. Variable fonts complicate the all or nothing picture. If a variable file is missing a single static style, commonly Bold, Figma keeps the original static file for that one style and substitutes the rest. The result is a single family that imports partly correct and partly substituted, which reads strangely in the report the first time you see it.

Two substitution failures that look different

Not every substitution looks the same once it lands on the page. Swapping body text to Inter changes the letterforms but keeps the words readable. Swapping an icon font does not. Font Awesome, which appears on roughly 9% of pages, maps individual characters to pictograms rather than letters, so a substitution turns a navigation icon or a social link glyph into the wrong shape or a blank box. Odd characters where icons used to be? Check the substitution report for an icon font before assuming the import broke.

There's also a platform gap worth knowing about if you work on a design team. ChromeOS and Linux users can only use Google Fonts plus Apple's SF Pro and SF Compact inside Figma; they can't install arbitrary local fonts the way Mac and Windows users can. A self hosted custom font on a page will substitute for every ChromeOS or Linux teammate, regardless of what's installed on anyone else's machine.

Reading the import report to find every swap

UnHTML resolves each text node's font against your installed fonts and Google Fonts first, and only falls back to Inter when neither matches. Every swap gets listed in the import report, so you can find exactly which layers changed without re checking the whole page by eye. The resolution happens entirely on your machine. Nothing about the page's content gets uploaded anywhere to make that decision.

A practical way to work through a report: scan it for substituted families first, then decide per family whether it's worth installing the real font locally as a TTF or OTF and re importing, or accepting Inter because the layout is a quick mockup rather than a pixel for pixel rebuild.

What this means before you trust an import's typography

For most pages, font substitution is the exception, not the rule. Google Fonts cover close to half of all font usage on the web and almost never substitute. The pages that do see swaps are concentrated in self hosted custom fonts, format mismatches between WOFF2 and the TTF or OTF files Figma can install, variable fonts missing a single style, and icon fonts whose failure mode is more visible than a simple font change.

Before you trust an imported page's typography, open the report. If a family you expected to see is missing, that's your signal to install it locally and re run the import rather than guessing. UnHTML surfaces that report automatically on every import, in line with its own privacy policy of resolving everything locally, which is the fastest way to tell a clean import from one that needs a second pass.