Font fallbacks for a mobile app mockup: what to check

Your app mockup looks right on your computer, but the text shifts, wraps differently, or changes style on a phone. That can happen when the primary font is missing, a particular character is not included, or the phone uses a different fallback font.

Use the Installed Fonts tool to check typefaces on your computer and preview sample text. Then check the mockup on the mobile platforms you plan to support. A desktop font list can help you choose candidates, but it cannot tell you exactly which font a phone or app will use.

Check fallback fonts in your mockup

1. Open the Installed Fonts tool in Chrome or Edge on a computer. Its full font list works in those browsers on computers, not as a complete inventory of phone fonts.
2. Preview the text you expect the app to show. Include a heading, a long button label, numbers, punctuation, accented letters, and any symbols or languages your audience needs.
3. Choose possible fallback families that fit the design. For a web-based mockup, a stack might be font-family: "Brand Sans", system-ui, -apple-system, "Segoe UI", sans-serif;. Keep the generic family, such as sans-serif, at the end.
4. Preview the mockup at narrow phone widths and with longer translations. Check line breaks, button sizes, and text that sits near the edge of a card or screen.
5. Test on actual iOS and Android devices, or an appropriate device preview, before handoff. Check the font in the app itself, not only in a desktop design file.

If you are preparing a font handoff, see how to check if a font installed correctly. The key is to test both the font you intend to use and the alternatives that might appear when it is unavailable.

What the results mean

The primary font appears in the font list

Your computer has that font available, so it can preview the typeface locally. This does not mean the font is installed on a tester's phone, included in the app, or permitted for embedding. Confirm how the app will deliver or reference it, and check the font license before distributing it with an app.

A character looks different from the surrounding text

The font may not contain that character. A browser or app can use another font for just the missing glyph, the small drawing used for one character. This can make an accent, currency symbol, emoji, or non-Latin character appear heavier, taller, or misaligned. Test the actual characters used in your interface, not only the alphabet.

Text wraps at a different word or button

Fallback fonts have different letter widths and spacing. Even two similar-looking sans-serif fonts can make a sentence longer or shorter. Leave room for text to grow, especially in translated screens, error messages, and buttons. Avoid sizing a text box so tightly that one font change clips the final line.

The typeface looks right but the bold or italic style does not

The fallback family may not have the weight or style you requested. The system may substitute a nearby weight or create a synthetic bold or italic appearance. Check regular, medium, bold, and italic text separately, and do not assume a family available on your computer has every style available on a phone.

Your desktop preview and phone do not match

The Installed Fonts tool reports fonts available to the computer running the browser. It does not inspect an iPhone or Android font library, and it cannot identify which fallback a native app will select. Treat its previews as a way to compare candidates, then use device testing to confirm the final appearance.

How to make fallbacks more reliable

1. Use a short, intentional font stack. Put the preferred family first, then sensible platform or generic alternatives. A stack such as "Brand Sans", system-ui, sans-serif gives a web interface a fallback route, but it does not guarantee identical letter shapes across platforms.
2. Check what is installed on the design computer. On Windows 11, open Settings › Personalization › Fonts to review installed families. On macOS, open the Font Book app from Applications. The Installed Fonts tool can also preview your own sample text in available computer fonts.
3. Set flexible text dimensions. Let labels wrap when appropriate, allow buttons to grow with their text, and avoid fixed heights that cut off descenders or a second line. Check the smallest supported screen width as well as the default mockup size.
4. Test the characters your app actually uses. Include names, accented characters, punctuation, currency, and scripts relevant to your users. If a font lacks required glyphs, choose a family with broader character coverage or verify the fallback appearance on each platform.
5. Test font weights and spacing on devices. Review regular and bold text on both iOS and Android. If your mockup becomes a native app, confirm the font-family names and font resources with the app implementation rather than assuming a CSS stack controls native text.
6. Keep room for content changes. Use realistic long labels and translations before finalizing the layout. If a line wraps badly, adjust the layout or wording instead of relying on one font's exact width.

Why fallback testing matters for mobile

Fallback does not always replace an entire paragraph. A system can draw most text in the chosen family, then use a different font for a symbol or character that is missing. This is why a short English sample may look perfect while a localized screen has one odd-looking word or symbol.

Also distinguish a web mockup from a native app. A web view can follow CSS font-family rules, while a native interface may use platform-specific font names and resources. In either case, the mockup on your computer is only one part of the check. Confirm how the shipped app renders the same text on the phones you support.

Use local font previews to narrow your choices, then verify the actual app with representative text on real devices before treating the fallback as final.