The serif fallback check: what happens when a web font doesn't load

How a font stack falls back

A font-family declaration is a list. The browser tries the first family; if it isn't available, it tries the next, and so on, ending with a generic family such as sans-serif, serif or system-ui. If no family is named or none is found, most browsers default to a serif, which on many systems means Times New Roman.

That's why the end of the stack matters as much as the start. A page designed in a geometric sans with font-family: "Some Sans", serif looks fine until the web font fails, then turns into a newspaper. Even when the font does load, there's often a brief moment before it arrives where the fallback is shown; if the fallback is a serif, every page load starts with a visible jump in style.

What the gate matches

The check reads every font and font-family declaration in the page's styles, inline style attributes included, and fails if one of them contains a serif face. It treats these as serif:

• The generic serif keyword. sans-serif is fine; the check deliberately skips it.
• Common serif families by name: Georgia, Times, Garamond, Baskerville, Playfair, Merriweather, Lora, Cormorant, Crimson, Didot, Bodoni and Caslon.
• Slab serifs: any family with Slab in its name.
• Serif families loaded from Google Fonts: a font link whose family name contains Serif, such as a Noto Serif or an IBM Plex Serif.

A failing page is refused with a message naming “sans-serif type only”, and the detail quotes the declaration it found, so you can see whether it was a fallback or a family choice.

Read the label carefully: sans-serif only

The rule began as a guard against serif fallbacks, but as written it does more. Because it matches serif families by name as well as the generic keyword, a page that deliberately sets its headings in Playfair or its body in Georgia is refused just as a broken fallback would be. The label is accurate: published Anticode pages use sans-serif type only. That's a real constraint if your brand uses a serif, and worth knowing before you ask for “an elegant serif headline” in a change request: if a serif reaches the page, publishing is refused until it's gone.

How design-engine pages are built

Each of the seven design systems uses one sans-serif web font, loaded from Google Fonts, and a stack that ends safely:

--font: "Geist", system-ui, sans-serif

with Geist replaced by the system's own face: IBM Plex Sans, Jost, Fredoka, Archivo, Figtree or Inter Tight. If the web font fails, the page drops to the visitor's operating system interface font, and failing that to whatever sans-serif the browser has. Either way the page keeps a sans look close to the one designed. The fonts are requested with display=swap, which shows the fallback while the web font loads instead of hiding the text. More on this in system font stacks and web font performance.

Limits

• No serif typefaces, even on purpose. If you need a serif for your brand, Anticode's published pages can't carry it today. The Next.js export gives you the code to change.
• Name matching has edges. A sans family whose name happened to contain one of the matched words would be refused. Check the quoted detail if the failure surprises you.
• Declarations only. Text drawn inside images or SVG isn't read by this check.
• Apps too. Model-written apps go through the same gate and are repaired against it before you see them, so their type will also be sans.

Questions people ask

Why does my website show Times New Roman?

Usually because the web font didn't load and the font stack ended in serif, or named no generic family at all. Ending the stack in system-ui and sans-serif avoids it.

Can I use a serif font on an Anticode site?

Not on a published page. The serif fallback font check refuses serif families as well as serif fallbacks, so published pages are sans-serif only.

Is sans-serif in my stack a problem?

No. The check skips sans-serif and only matches serif on its own or named serif families.