Why web fonts look different abroad, and how to test it
The landing page looked right on the office monitor, with the headline in the brand serif and the spacing matching the mockup. The client signed off. Two days later their team in another country sent a screenshot, and the headline was set in a plain system sans.
A second message said the text dropped a few lines a moment after the page opened. The code was identical in both views, so the cause sat in the network between the page and the visitor, and in the rules applied along the way.
Web fonts depend on separate requests that can fail, wait or arrive incomplete, and each outcome looks different on screen. On a fast office connection in the country where the site was built, most of these failures never appear.
What changes when the page loads in another country
A browser draws text in a web font only after it downloads the font file, which often comes from a different server than the page. Until the file arrives, or if it never does, the browser uses the next font in the font-family stack. The font-display descriptor decides whether that fallback text appears immediately or stays invisible for a short period.
Location affects that second request. Networks that block Google services, such as those in mainland China, can stop fonts served from Google’s font servers while the rest of the page loads normally. Each cause below leaves a different mark on screen, so the screenshot from abroad already tells you where to start looking.
| Cause | What the visitor sees | How to catch it |
|---|---|---|
| The font server is unreachable from the visitor’s network | Text stays in the fallback font for the whole visit | Font requests fail or time out when the page loads from that country |
| A consent tool holds back the font request | Fallback font until the visitor accepts, then a visible swap | Decline consent and check whether any font request goes out |
| The font file arrives late on a distant connection | Invisible text for a moment, or a jump when the font swaps in | Watch the render frame by frame on a slow connection |
| The localized copy uses characters the font file does not contain | Some letters or words appear in a different font from the rest | Proofread the localized pages for mismatched accented or Cyrillic letters |
The privacy side of loading fonts from someone else’s server
On 20 January 2022, the Munich Regional Court (case 3 O 17493/20) ordered a website operator to pay a visitor 100 euros in damages. The site loaded Google Fonts from Google’s servers, which passed the visitor’s IP address to Google without consent.
A font request is also a data transfer. Every request carries the visitor’s IP address to whichever server answers it, and that is why some consent tools hold back third-party font requests until the visitor agrees.
Fonts stored on the site’s own server avoid that transfer. The browser never contacts a third party to get them, so the consent tool has no font request to hold back. Self-hosting helps reachability too, since a visitor who can load the HTML can also load fonts from the same domain, and a network can no longer block the font host while letting the site through. Check that the font license permits self-hosting before you copy the files over.
How to test font loading from another country
Throttling the office connection reproduces a slow network, yet it cannot reproduce blocking or regional consent rules, because both depend on where the request comes from. A font server that answers your office IP may never answer a visitor’s, and a consent banner that a site shows only in certain countries will not appear for you at all. To test a website from another country as a local visitor sees it, load the page through an IP registered to a local internet provider in that country, so the site and its font server treat the request like any other local one. A static address keeps every run on the same IP, which makes results from separate days comparable.
- Load the page through a connection in the target country with the browser cache disabled, and take a screenshot as soon as any text appears.
- Open the network panel, filter by font files, and look for requests that fail, stay pending, or finish well after the rest of the page.
- Clear cookies, reload and decline consent. Check whether any font request goes out, and note which font the headline and body text use.
- Switch to the localized version and read the headings, buttons and body copy for characters that look out of place next to their neighbors. Each one is a glyph the font file does not contain.
- Compare the first paint with the final render in the browser’s filmstrip view or in screenshots taken a moment apart. Note how far the headline and first paragraph move when the font swaps in.
- Run the test again with network throttling set to a slow mobile profile, so the font file takes even longer to arrive.
A fallback stack that survives the trip
Start with font-display. With swap, the browser shows fallback text at once and replaces it when the web font arrives, which suits headlines where the brand face matters. With optional, it uses the web font only if the file is ready almost immediately and otherwise keeps the fallback for that page view, so long body text stays put on a slow connection.
A swap only looks bad when the two fonts take up different amounts of space, so the next step is a font fallback with matching proportions. Declare a second @font-face that points to a system font through local(). Then use size-adjust to scale its glyphs to the web font’s width, and ascent-override and descent-override to match its line height. List that face right after the web font in the font-family stack.
@font-face {
font-family: “Brand Serif Fallback”;
src: local(“Georgia”);
size-adjust: 104%;
ascent-override: 92%;
descent-override: 24%;
}
h1 {
font-family: “Brand Serif”, “Brand Serif Fallback”, serif;
}
The percentages in this example are placeholders. To get yours, overlay the two fonts at the same size and adjust until the line breaks match.
Then split the font by script. When Latin, Cyrillic and Greek each get their own file and unicode-range, the browser downloads only what a page needs, and a localized page loads the characters its copy uses instead of falling back for them. Self-hosting makes the split practical, because you decide which subsets exist and which pages reference them.
Run one country before the next launch
Pick the foreign market the client cares about most, run the six steps against the homepage, and save the screenshots next to the approved design file. Comparing the two sets shows which part of the font stack to fix first, and it leaves the client a record of what visitors abroad were seeing.