Web font not loading on iPhone or Android? How to fix it

Updated October 17, 2026 · Covers: Your web font was not applied

You picked a typeface, added an @font-face rule, and it looks right on your laptop. Then someone sends a screenshot from their phone and the headings are in Times New Roman, or half the letters look different from the rest. The font didn't load, or it loaded but doesn't contain the characters on the page. This guide covers the usual reasons and how to make web fonts dependable on mobile.

What it means

When a browser can't use your web font, it falls back to the next font in your font-family list, and if that's a generic family like sans-serif, to whatever the system provides. That happens in two situations:

• The font file failed to load: wrong URL, blocked by CORS, an unsupported format, a server error or a timeout.
• The font loaded but lacks the glyphs: the file is a subset (often Latin only) and your text uses characters outside it, such as accented letters from latin-ext, Cyrillic or Greek. The browser then draws just those characters from a fallback font, so words come out in a mix of two typefaces.

Why it matters

A fallback font is not just a cosmetic change. Fonts have different widths and heights, so a fallback changes where lines break. Headings that fit on one line may wrap to two, buttons can clip their labels, and when the web font arrives late the whole page can jump, which counts toward Cumulative Layout Shift. It's also hard to notice from your own computer, because the font is usually cached there or installed locally.

How MobileCheck finds it

MobileCheck loads the page fresh, with no cache and no locally installed design fonts, in WebKit for Apple devices and Chromium for Android. For each web font family that is used for a meaningful amount of text, we check whether the browser reports the font as loaded, and whether text set in that family actually renders with it rather than with a fallback. The report names the family and the likely reason, for example "failed to load" or "missing glyphs". Because Apple devices run on WebKit, this is also a quick way to catch Safari-only font problems without owning an iPhone; see testing a website on iPhone.

Common causes and fixes

1. CORS on cross-origin fonts

Fonts loaded from a different origin, such as a CDN, a separate static domain or even www versus the bare domain, must be served with a CORS header. Browsers refuse cross-origin fonts without it. The server hosting the fonts needs:

Access-Control-Allow-Origin: https://www.example.com

Use * if the fonts are public. Check the browser console: a blocked font usually produces a clear CORS error. When you preload fonts, add crossorigin, or the preloaded file won't be reused:

<link rel="preload" href="/fonts/inter-latin.woff2"
      as="font" type="font/woff2" crossorigin>

2. Wrong path or file name

URLs in @font-face are resolved relative to the stylesheet, not the page. Many servers treat file names as case-sensitive, so Inter.woff2 and inter.woff2 are different files. Open the font URL directly on your phone; if it doesn't download, neither will the page.

3. Format

WOFF2 is supported by every current mobile browser and is the smallest format, so it's the one to serve. Older formats like EOT and SVG fonts aren't needed today; if you list several formats, put WOFF2 first and make sure the format() hint matches the file:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin.woff2") format("woff2");
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}

4. Missing character subsets

Font services commonly split a typeface into subsets such as latin, latin-ext, cyrillic and greek, each with a unicode-range. The browser downloads only the subsets your text needs, which is efficient, but only if you included them. If you self-host only the latin file, characters like ą, ő, ş or any Cyrillic letter fall back to another font:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-cyrillic.woff2") format("woff2");
  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
  font-display: swap;
}

Keep the same font-family name for every subset; the browser combines them.

5. Slow loading and font-display

The font-display descriptor controls what happens while a font downloads. With the default behaviour many browsers hide text for a short period first, which on a slow mobile connection can mean a blank page, then a fallback. swap shows the fallback immediately and swaps in the web font when it arrives; optional uses the web font only if it's available very quickly, which avoids late swaps entirely. Either is better than invisible text.

6. Restricted modes on the device

Some privacy and security settings limit web fonts. Apple's Lockdown Mode, for example, can block many web fonts in Safari. You can't control this, which is one more reason to have a good fallback.

Choose a fallback that fits

List a similar system font before the generic family, and consider a fallback face with adjusted metrics so the swap moves less text around:

@font-face {
  font-family: "Inter Fallback";
  src: local("Arial");
  size-adjust: 107%;
}
body {
  font-family: "Inter", "Inter Fallback", system-ui, sans-serif;
}

The right size-adjust value depends on the two fonts; tools and frameworks can calculate it for you. Support for related descriptors such as ascent-override differs between browsers, so treat them as a refinement. MDN has a reference for @font-face descriptors.

How to check the fix

Run the free check with at least one iPhone and one Android phone, and compare the headings on the screenshots with your design. The font warning should be gone. For a closer look, include an iPhone in the check — the website renders iPhones with WebKit — and look at pages that use accented or non-Latin text.

Related guides