· rust, rendering, security, explainer
Font technology is quietly being rewritten in Rust

Font technology is not all moving to Rust, but the parts that parse untrusted font files increasingly are, and the reason is security: font parsers are complex, historically bug-ridden, and exposed to hostile files from the network, so Google and others are rewriting them in a memory-safe language. Chrome already ships a Rust replacement for parts of FreeType, Google’s font compiler is being rebuilt in Rust, and the standard text shaper has an official Rust port. The platform stacks owned by Microsoft and Apple are not moving; the new infrastructure is.
Why fonts are the proving ground

Both the Chromium project and Microsoft’s security team have published the same figure from their own bug data: roughly 70 percent of serious security vulnerabilities are memory-safety problems, the class of bug (use-after-free, buffer overflows) that Rust is designed to make impossible. Font code is where that class concentrates. A font file is not passive data: TrueType hinting and CFF charstrings are bytecode for small virtual machines, which makes a font closer to a program than a picture, and programs fed to a parser by strangers are an attack surface. A FreeType heap overflow, CVE-2020-15999, was exploited in the wild through Chrome (it is in our bizarre font uses file), and Project Zero has repeatedly found exploitable bugs in font code on every platform.
Google’s font team says keeping up with the FreeType issues fuzzing finds costs at least a quarter of a full-time engineer, forever, and they still miss some. The umbrella project is called Oxidize, and its stated goal is to move “shaping, rasterization, font compilation, and general font inspection and manipulation from Python & C++ to Rust.” Python is named a culprit too: the Google Fonts build tooling is, in their words, so slow that running it in production causes real pain.
The fontations stack

The core of the program is Fontations, a set of Rust libraries (crates, in Rust vocabulary) maintained by the Google Fonts team:
| Crate | Job |
|---|---|
| font-types | The shared vocabulary: core types from the OpenType specification |
| read-fonts | Parsing font files: zero-copy, zero-allocation, memory-safe by construction |
| write-fonts | Modifying and writing font data, and compiling font files |
| skrifa | Reading glyphs at size: metadata, outline scaling, and hinting |
| skera | Subsetting fonts (in the same repo) |
Skrifa’s own documentation states its purpose without hedging: it exists to replace FreeType in Google applications. The download counts on crates.io, Rust’s package registry, show these are not experiments. The parsing and glyph crates each count tens of millions of downloads, and the striking part is the recency: for read-fonts and skrifa, more than half of all downloads ever recorded arrived in the most recent ninety days.

The font projects also ride a broader tide: search interest in the Rust language itself, flat for years, stepped up sharply from 2022, the same moment the fontations repo was created.

Skrifa inside Chrome
Trial run: less common formats, color fonts and CFF2
All web fonts on Linux, Android, ChromeOS; fallback on Windows + Mac
The stated plan: OS fonts too, starting with Linux and ChromeOS
The proof that this is production technology and not a research blog came from the Chrome team, in a March 2025 post titled Memory safety for web fonts. Chrome’s graphics library, Skia, historically used FreeType to load metadata and letterforms. Google built a new Skia font backend on Skrifa and rolled it out in stages. Chrome 128 (August 2024) used it for less common formats such as color fonts and CFF2, as a trial run. Chrome 133 (February 2025) extended it to all web fonts on Linux, Android, and ChromeOS, plus web fonts on Windows and Mac whenever the operating system cannot handle a format itself. System fonts came next: Chrome 136 began routing system font handling through Fontations, the Rust stack that includes Skrifa.
Scope matters here, because the headline version (“Chrome replaced FreeType with Rust”) overstated it at the time: the rollout was staged, platform by platform. It no longer overstates Blink, though: Chrome 145 removed FreeType from Blink, completing the move to the Fontations stack built on Skrifa. The early returns are the argument in miniature. Fuzzing the Rust stack since June 2024 found 39 bugs, and in the team’s words, none of them were security critical: visual glitches and controlled crashes, the failure modes you want, instead of the exploitable memory errors the same effort kept finding in C.
The compiler follows: fontc

Parsing and rendering are half the stack; the other half is building the fonts. Google Fonts’ production compiler is fontmake, a Python tool, and its Rust replacement is fontc. Its stated motives are blunt: the Python compiler is too slow and cannot plausibly be made fast enough, and consolidating on Rust is strategy. The honest status, also from the project itself: fontc is not the production default yet. It compiles a growing share of families correctly. A public tracker, fontc_crater, continuously builds thousands of font sources with both compilers and diffs the outputs. The README describes the current phase as “moving towards using fontc exclusively for all Google Fonts builds.” Google publishes no headline speed multiplier for it, and neither will we; the 2022 experiments that fed into the project reported gains from marginal to about 3x depending on the workflow.
Even shaping fell

Shaping, turning characters into positioned glyphs, is the subtlest part of the stack, and for a decade the answer everywhere was HarfBuzz, in C++. The Rust world first got rustybuzz, a line-by-line port that matched HarfBuzz’s behavior and passed nearly all of its shaping tests. Rustybuzz’s repository is now archived, and its README tells users to switch to its successor: HarfRust, maintained in the HarfBuzz project’s own organization and rebuilt on top of read-fonts. It currently matches HarfBuzz version 14.5.1, at a self-reported cost of under 25 percent speed on common fonts. Google Fonts has a written plan, dated March 2025, for productionizing it. The adoption curve is the fastest in this story: the HarfRust crate was first published in June 2025 and passed 13 million downloads within sixteen months. Projects that built on rustybuzz, cosmic-text among them, have already migrated.
The app and UI stack

Google is the biggest mover, not the only one. The Linebender collective, an open-source group whose contributors include Google engineers, is building a complete Rust text stack for applications: Fontique for font discovery and fallback, Parley for rich text layout (line breaking, bidi, selection) on top of Fontique, HarfRust, and Skrifa, and swash, an independent crate covering introspection, shaping, and rendering. Pop!_OS uses the sibling library cosmic-text (HarfRust for shaping, swash for rendering) as the text engine of its COSMIC desktop. For GPU applications, glyphon pairs cosmic-text with a texture atlas and is the standard starting point for text in Rust WebGPU programs, the same approach our WebGL and WebGPU text post describes in the browser world. The Servo browser engine, written in Rust, loads fonts through its own font-kit library. And the tools lag the libraries, as tools do: the Rust font editors, Runebender and Bezy, are early experiments (Runebender has been untouched since 2023), nowhere near displacing FontLab or Glyphs.
What is not moving

The counterweight, so the picture stays honest. DirectWrite and CoreText remain C++ under Microsoft and Apple, with no public Rust migration. HarfBuzz’s C++ original is still the reference implementation; HarfRust’s job is to chase it version by version. FreeType remains the default rasterizer across most of the open-source desktop. Firefox, despite being the browser that popularized Rust, shows no Rust font migration at all: its bundled HarfBuzz was updated again in late 2025, still in C++. And fontTools, the Python library the whole industry leans on, is not being rewritten; fontc replaces the compiler pipeline around it, not the library.
So the answer to “is it all transitioning” is: the frontier is. Anything that parses files from the network, builds fonts at scale, or starts a text stack from scratch in 2026 is disproportionately written in Rust, and the largest browser already renders much of its web text through Rust font code. The installed base stays C and C++, and will for years. Font transitions are measured in decades; this one is simply further along than most people have noticed.