Why Does My Font Look Different on Other Computers?

How fonts reach the visitor

A web page does not contain its fonts. It contains text and a request: "display this in Inter, or failing that in Helvetica, or failing that in any sans-serif". The visitor's browser looks for those fonts on the device, and if the page provides its own font files, downloads them. Whatever the browser ends up with is what the visitor sees.

So when the site looks right on your machine and wrong on a colleague's, the page has not changed. The set of fonts available to the browser has.

Cause 1: the font is installed on your machine and not theirs

The most common cause among designers. The mockup used a font that is installed on the designer's computer; the site's CSS names that font; it looks perfect to the designer and falls back to Arial for everyone else. The tell is that it looks right only on the machines that have the font installed, which is usually one.

The fix is to serve the font from the site as a web font, so every visitor's browser downloads it. This needs a licence that permits web embedding, which is a different licence from the desktop one; free families such as those on Google Fonts allow it, and commercial foundries sell it separately.

Cause 2: the web font failed to load

The site does provide the font, but on some visits it does not arrive: the font file is blocked by a content security policy, served from a domain that a corporate firewall or ad blocker refuses, missing a CORS header when loaded from a CDN, referenced by a wrong path after a deploy, or simply slow, so the browser gave up and showed the fallback. Some visitors have also disabled web fonts entirely for accessibility or privacy.

The tells: it works for most people and not for a specific network or browser; the browser's console shows a failed request or a CORS error for the font file; the page briefly shows the right font and then switches, or the reverse.

The fix is to serve the font from your own domain, in WOFF2, with correct headers, and to test in the browser's network panel that the file loads with a 200 status. If the font is loaded from a third party, check that the third party is reachable from where your visitors are. Serving fonts yourself also has performance and privacy advantages.

Cause 3: the fallback stack is doing its job badly

Every font declaration should end with a list of alternatives. font-family: Inter, Helvetica, Arial, sans-serif means: try Inter, then Helvetica, then Arial, then whatever the system's default sans-serif is. If the stack is just Inter, the browser's default, often a serif, appears when Inter is unavailable, and the page looks radically different rather than slightly.

A good fallback is a font with similar proportions that is widely installed, so that the page's layout survives the substitution. Tools exist to tune fallback fonts with size-adjust so that line lengths and heights match the intended font closely, which also reduces the layout shift when the web font arrives.

Cause 4: the same font renders differently

Even when the identical font file loads everywhere, Windows, macOS, Linux, Android and iOS rasterise text with different engines and different hinting and anti-aliasing. Text on Windows tends to look thinner and sharper; on macOS heavier and smoother. Older Windows versions render some fonts noticeably worse. Sub-pixel rendering, screen density and the user's own display scaling all contribute.

This cannot be fixed. It can be minimised by choosing fonts that were designed and hinted for screen use, avoiding very light weights that Windows renders as broken hairlines, and testing on both operating systems rather than only the one on the designer's desk. Some CSS properties, such as -webkit-font-smoothing, change rendering on macOS only and often make Windows comparisons worse rather than better.

Cause 5: weights and styles that were never provided

The page uses bold, and the bold file was never included, so the browser fakes it by smearing the regular weight. The page uses italic with no italic file, and the browser slants the upright. Faux bold and faux italic look wrong in ways people cannot always name. The fix is to load every weight and style the design uses, and no more, since each is a separate download.

The checklist for consistent type

• Use a web font with an embedding licence; do not rely on installed fonts for anything other than the fallback.
• Self-host WOFF2 files from your own domain, with @font-face rules for each weight and style actually used.
• Set font-display: swap or optional so text is never invisible while waiting.
• Write a full fallback stack of similar, widely installed fonts, ending in a generic family.
• Preload the one font file the first screen needs.
• Check the network panel on a machine that is not yours; the font request should return 200 and the correct content type.
• Test on Windows and macOS, and on a phone. Accept small rendering differences; fix large ones.

What to accept

Perfect consistency across devices is not available on the web and never was. The realistic goal is that every visitor sees the intended font, loaded quickly, in the correct weights, rendered as well as their operating system allows, and that when the font cannot load, the fallback is close enough that the design still works. That is achievable in an afternoon, and it is the standard our typography choices are made against. If a site's type is misbehaving and the cause is not obvious, book a call and we will find it.

Common questions