How to base64 fonts vs external font files: performance tradeoffs
- Step 1Measure the cost on your site — Open DevTools Network tab. Note your CSS file's transfer size with and without base64-inlined fonts. The inlined version is typically 30–40% larger and blocks rendering until the entire CSS arrives.
- Step 2Check HTTP/2 multiplexing — On HTTP/2 (effectively all production sites), the connection-overhead penalty of multiple requests is near zero. External woff2 files load in parallel with the CSS — total page load is faster, not slower.
- Step 3Pick the right strategy — Web: external WOFF2 + preload. HTML email: base64-inlined. Offline PWA: base64 in the cached service worker payload. Kiosk app: base64. The rule: inline only when external resources can't be fetched.
Frequently asked questions
Doesn't base64 save HTTP requests?+
Yes — but on HTTP/2 the per-request cost is microseconds. The 33% size penalty far outweighs the saved request. Pre-HTTP/2 (HTTP/1.1) the equation favoured inlining; modern stacks reverse it.
What about cache hits?+
Inlined fonts can't be cached separately from the CSS. Every CSS update busts the font cache too. External WOFF2 files have content-hash filenames that cache forever — visit two pages on the same site, the second visit reuses the font for free.
Is there a Lighthouse penalty?+
Lighthouse doesn't directly penalise inlined fonts, but the larger CSS hurts First Contentful Paint and the blocked parallel load hurts LCP. Both metrics show measurable degradation when fonts are inlined.
Does base64 help with CDN caching?+
Marginally — inlined CSS caches together. But external WOFF2 caches better long-term because fonts change far less often than CSS. A typical site updates CSS weekly and fonts annually; separate caching wins by orders of magnitude.
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.