How to validate font format in ci/cd pipelines
- Step 1Write a validation script — Walk every *.ttf, *.otf, *.woff, *.woff2 in your fonts directory. For each, read the first 4 bytes and check the magic against the expected format from the file extension.
- Step 2Wire into GitHub Actions — Run the script in your CI workflow as a separate step. Exit non-zero if any file's actual format doesn't match its extension. Typical run time: under 1 second for design systems with 50+ fonts.
- Step 3Catch TTC accidentally renamed to TTF — TTC magic 'ttcf' must never appear in a .ttf file. Add an explicit check — TTC files in production cause silent renderer failures because most browsers don't support TTC.
Frequently asked questions
Should I validate every commit?+
Yes — fonts change rarely, but a single corrupt commit can sit undetected for months. Running validation as a CI gate prevents production incidents at minimal cost.
What about checksum validation?+
Format identification is the first layer. For deeper validation, add a SHA-256 fingerprint check (the JAD Fingerprinter tool) against known-good upstream hashes. Catches subtle corruption that format identification misses.
Can I run this against externally-fetched fonts?+
Yes — the validation logic runs against any file regardless of origin. Useful when consuming Google Fonts CDN downloads or third-party design system packages.
Does it slow down builds?+
Negligibly. Reading 4 bytes per file is microseconds; the file-system walk dominates. Even with 100+ fonts, the validation step adds under 200 ms to CI runs.
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.