How to fout vs foit: understanding font loading behaviour
- Step 1FOIT: invisible until loaded — block, fallback (briefly), and auto (often) produce FOIT. Browser shows nothing, waiting for the font. If the font is slow, users see invisible text — usually bad UX.
- Step 2FOUT: fallback then swap — swap, fallback (after timeout), and optional (if cached) produce FOUT. Browser shows fallback immediately, swaps when loaded. Visible text from the start; text appears to 'flash' when fonts swap.
- Step 3Pick the lesser evil — FOUT is almost always better than FOIT — visible text > invisible text. Modern best practice: swap (always FOUT) for most surfaces. Use size-adjust to make the FOUT swap visually invisible.
Frequently asked questions
Why does FOIT exist if it's bad?+
Historical. Early web fonts thought 'right font, even if delayed' was the right tradeoff. By 2018 the consensus shifted: visible-fast > invisible-then-correct. swap became the default.
Can I eliminate FOUT?+
Mostly yes via size-adjust + ascent-override descriptors that match the fallback's metrics to the web font. The swap still happens but is visually imperceptible. The Font Metrics Analyser provides the values.
What about prefers-reduced-data?+
Some browsers expose a 'prefers-reduced-data' media query; you can downgrade to font-display: optional or skip web fonts entirely. Future-friendly UX consideration; not yet widely supported.
Privacy first
Every JAD Font tool runs entirely in your browser using opentype.js and the wawoff2 WASM Brotli encoder. Your fonts never leave your device — verified by zero outbound network requests during processing.