How to automate font base64 encoding in your build pipeline
- Step 1Author normal CSS — Write @font-face declarations using regular url() references during development. The dev experience stays normal — no base64 noise in the editor.
- Step 2Build-time replacement — Run a Node script that reads the CSS, finds every url() reference to a local .woff2 file, encodes the file as base64, and writes the inlined version to dist/.
- Step 3Validate the output size — Add a CI check that warns if the inlined CSS exceeds your budget (e.g., 200 KB). Base64 fonts inflate fast; an alarm prevents accidental 3 MB CSS shipping to production.
Frequently asked questions
Should I gzip the CSS afterwards?+
Yes — base64 compresses well via gzip/brotli (around 20% reduction). The over-the-wire transfer is much smaller than the parsed size, but both metrics matter for performance.
What about Webpack/Vite plugins?+
Both ecosystems have url-loader / asset-modules that inline files under a size threshold. Same idea but framework-specific. The standalone Node script works regardless of bundler.
Can I selectively inline only some fonts?+
Yes — the script can filter by font filename or size. Common pattern: inline the critical hero font, leave secondary fonts as external requests. Best of both worlds.
How do I revert if base64 breaks something?+
Keep the source CSS unchanged in source control. Build-time inlining is a deploy-time transform — reverting is just "don't run the inline step" on the next deploy.
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.