Base64 Fonts in 2026: Measured Inflation, the Three Failure Modes, and an Inline Validator

We ran a 28 KB WOFF2 with newlines wrapped every 76 columns through lightningcss.transform({ minify: true }). The output was @font-face{font-family:S} — the src URL was discarded entirely. No warning. The font silently vanishes after build. Some encoders (RFC-2045-compliant MIME ones, including openssl base64 without -A) wrap at 76 columns by default. Strip whitespace before embedding: base64 -w 0 on Linux, openssl base64 -A, or in Node just .toString('base64') which never wraps.

Replace every + with - and every / with _ in a base64 payload, run it through lightningcss — the minifier passes the URL-safe characters through unchanged. Then the browser's atob throws Invalid character and the font fails to load. Standard base64 (RFC 4648 §4) is what data: URIs require; URL-safe (RFC 4648 §5) is for putting the payload in URL paths and query strings, not in data: URIs. If your encoder has a --url-safe flag, don't pass it for font CSS.

RFC 4648 requires base64 strings to be padded to a multiple of 4 with =. WHATWG's forgiving-base64 algorithm (which atob and the browser data: URI decoder use) re-adds the padding before decoding. lightningcss does the same. So you can strip trailing = chars and everything works — but a stricter consumer (a non-browser tool, a third-party CSS parser) may reject. Save bytes elsewhere; emit the padding.

RFC 2397 says an empty MIME in a data URI defaults to text/plain; charset=US-ASCII. The browser parses the @font-face block successfully, downloads the data URI, then refuses to interpret the bytes as a font because the MIME isn't a font type. There is no console warning. Always declare font/woff2 (or whatever format the bytes are) explicitly.

Outlook on Windows desktop renders email through Microsoft Word's HTML engine, not a browser engine. Word strips every @font-face rule regardless of whether the src is external or inlined. There is no workaround that gets your brand font into Outlook desktop — design the fallback so the email still looks like itself when the system font kicks in. The HTML email embedding guide covers the full Outlook-aware pattern.

If your Content-Security-Policy has a font-src directive (or falls back to default-src), it must explicitly include data: for browsers to load inlined font URIs. font-src 'self' allows /fonts/file.woff2 but blocks data:font/woff2;base64,... — the browser logs Refused to load the font 'data:...' because it violates the following Content Security Policy directive. The CSS itself parses fine; the font fetch is blocked. Update the header to font-src 'self' data:.

Both Webpack 5 and Vite default to inlining any imported asset smaller than 4 KB as a data URI in the bundled CSS. For small icon fonts and critical-text subsets this is exactly what you want. For full WOFF2 files (typically 20–60 KB each) it defaults to keeping them external. The threshold is a config option — assetsInlineLimit in Vite, Rule.parser.dataUrlCondition.maxSize in Webpack — so it's a deliberate choice masquerading as magic.

Browsers refuse to display SourceMaps larger than ~10 MB. A few inlined WOFF2 files (each ~30 KB → ~40 KB base64) inside a CSS bundle quickly pushes the SourceMap past that ceiling because the SourceMap embeds the source for each token. Strip data URIs from SourceMap inputs (postcss-discard-sourcemap-data or the equivalent in your toolchain), or build the @font-face CSS as a separate file with sourcemaps disabled.