A type foundry that runs in your browser.

Making a real font is a typography project. Most people just want their handwriting.

The tools that build production fonts (Glyphs, FontForge, RoboFont) assume you already speak typography: spacing, kerning, hinting, the difference between a contour and a component. A crafter who sells on Etsy, or someone who just wants their own handwriting as a typeface, hits that wall on day one. The capability exists. The on-ramp does not.

The brief I set was narrow. Take the one input a non-typographer can produce, an alphabet sheet or a page of handwriting, and return a font that installs cleanly on Windows, macOS, and the web. Simple enough for a Cricut crafter on the first try, with the depth a designer wants sitting one reveal away. And make the result worth showing, so finishing a font drops you onto a wall next to everyone else's.

The whole foundry runs in the browser.

Drop a sheet and the machine shows its actual work, not a spinner. It binarizes the image, finds the rows, slices each row into glyph cells, traces every cell into vectors, and assembles a real font. Nothing is uploaded to do any of it. Potrace runs the trace on the main thread, a Web Worker builds the OpenType binary off the main thread, and a WebAssembly build of wawoff2 compresses the result to WOFF2 in the tab.

• Three formats from one sheet: OTF, TTF, and WOFF2, built client-side from the traced outlines
• Sheet geometry detection cuts rows into glyphs with four cascading slicers (whitespace, anchored minima, connected components, ownership), and you can re-slice a row by hand when a letter is miscut
• Trace presets (glyph, logo, sketch) trade fidelity for smoothness; a fine-detail pass resamples first so serifs survive
• Color fonts (flat COLR/CPAL and gradient COLRv1) and single-line fonts for Cricut pens and plotters, each on its own path
• SFNT checksum repair: every table checksum and head.checkSumAdjustment recomputed, then verified again server-side on publish
• The engine's cache version is derived from its own bytes, so any change to the build code busts the browser cache automatically

The home is the library, not a landing page.

You land in the work: a wall of fonts rendered as live specimens rather than a name in a default face. Sort by popular or new, search by font or maker, filter by kind. The masthead cycles real faces, the same word re-rendered every few seconds, and that slot doubles as the daily feature. A nightly Cloudflare cron tallies the previous day's votes and promotes the most-liked, automatically, with a cold-start fallback to the house fonts.

Each font has a specimen page you can type into, with glyph count, file size, and formats sitting as quiet mono texture, plus downloads and an OFL, CC0, or personal-use license. Accounts stay light and are only needed to publish or favorite. Makers get a profile at their handle.

• better-auth for email and Google sign-in, with soft email verification
• D1 for fonts, votes, favorites and the featured set; R2 for binaries and avatars behind a visibility-gated /cdn route with edge caching
• KV-backed rate limits on every mutation; uploads validated by their signature bytes, not a content-type header
• Moderation: a normalized banlist, font and maker reports, soft-bans, and an admin queue
• Strict CSP (the wasm needs unsafe-eval, the font worker needs blob workers), HSTS, and the usual hardening headers
• A Playwright end-to-end suite plus a corpus regression over a seeded font set

What I picked, and what I didn't.

1. 01

   The whole foundry runs client-side.

   Tracing, the OpenType build, and WOFF2 compression all happen in the browser. That keeps a person's handwriting on their own machine, makes the maker free to run at any volume since no server does the work, and means a font is ready to download the instant it builds. The cost I paid is shipping a real font engine to the client (a Potrace trace, a Web Worker builder, and a wasm WOFF2 compressor) and keeping it small.

   Considered: a server-side font pipeline (rejected, it means uploading handwriting and paying per build), a desktop app (rejected, the whole point is no install)

2. 02

   Fix the checksums Windows actually enforces.

   An OpenType writer can leave a table checksum off by one when a table is not 4-byte aligned. Browsers and fontkit tolerate it, so the font previews fine, then fails to install on Windows. Fonthead recomputes every table checksum and the head.checkSumAdjustment as pure ArrayBuffer math, on the client and again server-side on publish, so a published font installs everywhere.

   Considered: trusting the writer's checksums (rejected, files previewed fine in Chrome and were refused by Windows), repairing only on the server (rejected, the client should hand back a valid file directly)

3. 03

   The home is the library, and the feature picks itself.

   Most product sites open on a marketing hero and a three-feature row. Fonthead opens on the work: a wall of real specimens, with a masthead that cycles community faces. The daily feature is computed by a nightly cron from the previous day's votes, not hand-curated, so the room stays current without anyone tending it. The fonts are the only color the page needs.

   Considered: a marketing landing page with a feature grid (rejected as the genre default), hand-picking the daily feature (rejected, it does not scale and it plays favorites)

Live at fonthead.dev, with the code in the open.

Fonthead is up. The wall has fonts on it, color faces included, each one built through the same maker. The masthead cycles them, the nightly feature rotates on its own, and a font goes from a photographed sheet to an installed OTF without a single upload of the source drawing.

Like this site, the repo is public, so anyone can read how the trace, the OpenType build, and the checksum repair actually work rather than take my word for it. It is early, version 0.1, built and run by one person, the same way every other build under this name is.