DEV Community: Zerrin Arslan

I built a browser extension that identifies fonts inside images. Here's what the recognizer actually does

Zerrin Arslan — Sun, 11 Oct 2026 14:59:40 +0000

Every "what font is this?" thread I have ever read ends the same way: someone posts a screenshot, three people guess, nobody is sure. The browser tools that exist (WhatFont and friends) read the CSS of a page, which is great until the lettering is a JPEG, a logo, a poster photo or a screenshot. Then they have nothing to read.

I run a font site, I had a catalog of a few hundred thousand fonts sitting in a database, and I had a 16 GB consumer GPU at home. I figured a font identifier that looks at pixels would be a weekend. It was a summer. This is what actually worked, what embarrassed me, and the numbers at the end.

Version 1: pretrained features and a nearest-neighbour index

The first version was the obvious thing. Render every font in the catalog into a few sample images, push them through an ImageNet EfficientNet-B2, store the embeddings, and at query time embed the user's image and return the nearest neighbours.

My self-test said 93% top-1. I was thrilled for about a week.

Then I built a benchmark from 137 real photos with known fonts (signage, book covers, packaging) and ran it. Top-5 accuracy: 0 out of 137. Not low. Zero. A hand-cropped, binarised, perfectly clean Montserrat photo returned garbage.

The self-test was lying because it used the gallery's own renders as queries. Same words, same rendering style. That measures near-duplicate retrieval, not font identity. An ImageNet backbone embeds "what word is this" and "what texture is this" far more strongly than "what are the letterforms". If you test an identifier, test it with words it has never seen and with photos you did not render yourself.

Version 2: teach the embedder what a font is

The fix was to fine-tune the backbone for font identity with an ArcFace head, on synthetic data I could generate at any scale:

around 35,000 font families as classes, with family-level labels (all weights of a family map to one class), because a photo of Montserrat Bold must not be a different class from Montserrat Regular
random real words from a 6k-word list, so the model cannot memorise the sample text
weight sampling along the variable-font axis, plus artificial thickening and thinning
augmentation that looks like the queries people actually send: perspective, uneven lighting, low resolution, JPEG artefacts, textured backgrounds
a later round added 12 "effect" renders per family: outline, 3D extrusion, glow, texture fill, emboss, pixelation, occlusion, wide tracking, multi-line layouts

Each round warm-started from the previous checkpoint. A pilot on 3,900 fonts took 23 minutes and moved unseen-word top-1 from 1% to 61%. The full run, about 5 hours on the home GPU, landed at roughly 74% top-1 and 86% top-5 on unseen words.

The number I care about most is generalisation to fonts the model never saw during training: about 59% top-1, against 65% for fonts it did see. Six points. That means adding a font to the index is "render 12 images, embed, append", no retraining. The index today holds 262,000 fonts and about 2.5 million render embeddings, and it is a plain tensor on CPU, not a vector database. Scoring is max(family prototype, best individual render). Median query latency is around half a second on 8 CPU threads; the GPU is shared with other jobs, so inference lives on CPU.

Things that broke in embarrassing ways

Tofu. Some fonts in a 170k gallery have no Latin glyphs at all (Khmer, Tamil, Arabic-only families). Rendered with Latin sample words, they produce rows of identical .notdef boxes. Those boxes became magnets: anything blocky matched them at 99%. I ended up scanning every gallery entry for renders made of near-identical connected components and blocking 453 of them. The lesson underneath: look at your gallery images, not just your metrics.

Weight blindness. Before family-level labels, a bold photo of a font with a regular-only class simply did not match. Obvious in hindsight.

The smart crop that was not. I wrote an automatic text-region cropper. On a ground-truth set it improved exactly 0 of 18 queries, but it pushed scores into the 95-98 range and doubled latency. Tight crops make everything look confident. It shipped turned off, and "score went up" is no longer accepted as evidence for anything.

Calibrating on 12 samples. I set a quality gate using a dozen hand-picked images. On 1,152 real queries it rejected 27% of legitimate uploads. Thresholds get calibrated on the full log now, nothing else.

Dark backgrounds. White text on a dark poster embeds differently from black on white. Inverting the image when its mean brightness is below 110 was a ten-line change and gave +2 correct on the 137-image benchmark. Cheapest win in the whole project.

Training on marketplace mockups. I tried adding designer preview images from a font marketplace as training data. The model learned the layout template of each designer instead of the typeface, and matched mockups to mockups. Preview images are search data, not training data.

Honest confidence

Cosine similarity is not confidence. A clipart image with no text at all can score 96%. So the ranking you see comes from vote aggregation across image variants (full image plus OCR line crops), not raw score, and the UI shows a "not sure, closest look-alikes" state when the top candidates cluster together instead of printing a fake 99%.

It is currently too cautious. In the comparison below it put the correct font at #1 on 9 of 12 images and still said "not sure" on 7 of them. That calibration is the next job, and it will be done on the real query log, see above.

The 12-image test

I rendered 12 known Google Fonts the way they show up in the wild: clean, textured, rotated, perspective-warped, blurred, low contrast, small JPEG, dark background. Then I uploaded the same 12 files to every free identifier I could reach through a browser. Score is the rank of the true family in the top 5.

Identifier	Top-1	Top-5	Note
FontBoxDL (mine)	9 / 12	12 / 12
Open-source identifier model (ResNet18, ~1k families)	7 / 12	9 / 12	strong on photos, lost the clean serif and marker
WhatFontIs	6 / 12	10 / 12	OCR letter step; collapses on small dark JPEGs
Font Squirrel Matcherator	5 / 6	5 / 6	blocked after ~15 uploads, only 6 tested
WhatTheFont	0 / 12	0 / 12	commercial-only catalog, so it structurally cannot name a free font; its paid look-alikes were reasonable

It is my test, on my images, so read it as "the approach works", not as a league table. The honest weak spot: script fonts. Lobster on a textured, rotated background came back at #4 behind three look-alikes.

The extension

The browser extension is the thin part. Manifest V3, no host permissions. Right-click an image, pick "Identify font in this image", and the extension sends only the image URL to my server, which fetches the image itself (with the usual SSRF guards) and returns the matches. Nothing is read from a page until you click. Because people kept asking, it also grew a hover inspector that reports the font that actually rendered an element (from the browser's font-face set, not the first name in the CSS stack) and a "fonts on this page" list.

Porting it to Firefox was mostly manifest work: background.scripts instead of a service worker, a browser_specific_settings.gecko block, and the data-collection declaration AMO now requires.

Links, if you want to poke at it: the web tool with cropping, the Chrome extension, the Firefox add-on page, and the longer, less technical write-up with five worked examples: How to identify a font from an image.

What kinds of images stump the identifiers you have tried? Hand-lettering, neon, chrome effects, tiny screenshots? Misses are the only training data that matters at this point, so I would genuinely like to see them.

I generated a pixel font in pure Python with fonttools (no font editor)

Zerrin Arslan — Thu, 25 Jun 2026 19:32:28 +0000

I needed a font last week — not to use one, to ship one. Long story short, the cleanest way to get listed on the big font directories is to publish your own typeface, and I'm not a type designer. No FontForge, no Glyphs, no years of Bézier practice. So I did the programmer thing: I generated one in pure Python with fonttools. No GUI, no GPU, a few seconds of CPU. Here's how.

The trick: a pixel font is just rectangles

A pixel/bitmap typeface is the easiest kind to generate by code, because every glyph is a grid of filled cells. Define each letter as a 5×7 bitmap, draw a square for every "on" cell, and you have an outline. No curves to hand-tune.

G = {
  "A": ["01110","10001","10001","11111","10001","10001","10001"],
  "B": ["11110","10001","10001","11110","10001","10001","11110"],
  # ... A–Z, 0–9, punctuation
}

Drawing a glyph with a pen

fonttools gives you a TTGlyphPen. For each filled cell, draw a square contour:

from fontTools.pens.ttGlyphPen import TTGlyphPen

PX = 120  # cell size in font units
def make_glyph(rows):
    pen = TTGlyphPen(None)
    for ry, row in enumerate(rows):
        for cx, ch in enumerate(row):
            if ch == "1":
                x, y = cx * PX, (6 - ry) * PX  # flip: row 0 is top
                pen.moveTo((x, y)); pen.lineTo((x + PX, y))
                pen.lineTo((x + PX, y + PX)); pen.lineTo((x, y + PX))
                pen.closePath()
    return pen.glyph()

Assembling the font with FontBuilder

FontBuilder wires the glyphs, character map, metrics and metadata into a real .ttf:

from fontTools.fontBuilder import FontBuilder

fb = FontBuilder(1000, isTTF=True)   # 1000 units per em
fb.setupGlyphOrder([".notdef", "space"] + list(G))
fb.setupCharacterMap({ord(c): c for c in G} | {32: "space"})
fb.setupGlyf({"space": TTGlyphPen(None).glyph(),
              **{c: make_glyph(rows) for c, rows in G.items()}})
fb.setupHorizontalMetrics({g: (820, 60) for g in fb.font.getGlyphOrder()})
fb.setupHorizontalHeader(ascent=900, descent=-150)
fb.setupNameTable({"familyName": "Boxel", "styleName": "Regular", ...})
fb.setupOS2(); fb.setupPost()
fb.save("Boxel-Regular.ttf")

That's a working, installable font.

Three things that bit me

Lowercase. I only defined A–Z, so typing "hello" rendered as tofu (□□□□□). Fix for a caps-only design: map a-z to the same glyph as A-Z in the cmap, so lowercase shows the uppercase shape instead of blanks:

  for c in G:
      cmap[ord(c)] = c
      if "A" <= c <= "Z":
          cmap[ord(c.lower())] = c

The viewBox flip. Font Y goes up, your bitmap rows go down. (6 - ry) flips it. Forget this and your letters are upside down.
Name table completeness. Some validators want license URL (name ID 14) alongside the license text (ID 13). Cheap to add, saves a rejection.

Verify it before you trust it

Don't eyeball it — render every character:

from PIL import ImageFont
f = ImageFont.truetype("Boxel-Regular.ttf", 64)
# draw "HELLO hello 12345 Test!" and check: any boxes = missing glyph

If a cell comes out blank, the glyph or cmap entry is missing.

Result

I made three styles this way — square, dot-matrix, and stencil — by swapping the cell-drawing function (square vs circle vs notched). It's a family called Boxel, free for personal use. The whole thing is a single script; no design tool ever opened.

fonttools is one of those libraries that turns "I can't do that" into "oh, it's 80 lines." If you've ever wanted a custom display font and bounced off the editors, generating a pixel one in code is a fun afternoon. (And if you just want fonts to download, that's literally what I build.)

What would you generate — a bitmap font, an icon font, something weirder?

Render any font to a crisp SVG path in the browser with opentype.js

Zerrin Arslan — Tue, 23 Jun 2026 19:54:49 +0000

A designer asked me for a logo word as an SVG path — not a PNG, not "the font file," an actual <path> they could drop into Figma and a cutting machine. My first instinct was to screenshot it and trace it. Don't do that. If you have the font file, the outlines are already vectors — you just have to ask for them. Here's how I do it client-side with opentype.js.

The idea

A font glyph is a set of Bézier curves. opentype.js parses a .ttf/.otf and hands you those curves as an SVG path string. No tracing, no quality loss, no server.

Load the font and get a path

import opentype from "opentype.js";

const font = await opentype.load("/fonts/MyFont.ttf");

// getPath(text, x, y, fontSize) → a Path object
const path = font.getPath("Hello", 0, 150, 120);

// .toSVG() gives you the <path d="..."/> markup
const pathMarkup = path.toSVG(2); // 2 = decimal precision

That pathMarkup is a real vector outline of your text in that font. Wrap it in an <svg> and you're done.

Size the viewBox correctly

The gotcha is the canvas/viewBox. getPath draws from a baseline, so you need the bounding box to avoid clipping:

const bb = path.getBoundingBox(); // {x1, y1, x2, y2}
const pad = 16;
const w = (bb.x2 - bb.x1) + pad * 2;
const h = (bb.y2 - bb.y1) + pad * 2;

const svg = `<svg xmlns="http://www.w3.org/2000/svg" viewBox="${bb.x1 - pad} ${bb.y1 - pad} ${w} ${h}">
  ${path.toSVG(2)}
</svg>`;

Now the SVG is tightly cropped to the glyphs, whatever the text.

Download it from the browser

No backend needed — make a Blob and click a link:

const blob = new Blob([svg], { type: "image/svg+xml" });
const a = document.createElement("a");
a.href = URL.createObjectURL(blob);
a.download = "text.svg";
a.click();
URL.revokeObjectURL(a.href);

Things that bit me

CORS on the font fetch. opentype.load does an XHR/fetch under the hood; the font has to be same-origin or CORS-enabled or it silently fails. Self-host the file.
Licensing. Converting a glyph to a path is still using the font. Check the license allows it before you ship outlines of a commercial font.
Right-to-left / complex shaping. getPath does basic layout, not full HarfBuzz shaping. For Latin display text it's perfect; for Arabic/Indic you'll want a shaping engine.
Precision vs file size. toSVG(2) is plenty for cutting/printing. Higher precision just bloats the path string.

Why client-side is nice here

The whole thing runs in the browser: the user picks a font, types text, and gets an SVG without a single byte hitting a server. That's exactly how I wired up the font-to-SVG tool on FontBoxDL — handy if you want to see it in action or grab a quick cut file (it pulls from a library of 60k+ free fonts you can use as the source).

opentype.js is one of those libraries that makes a "hard" task almost embarrassingly short. If you're doing anything with fonts in JS — metrics, kerning, glyph inspection — it's worth an afternoon.

Anyone else using it in production? Curious what you've built.

Adding custom fonts to a Next.js app without the layout shift

Zerrin Arslan — Mon, 15 Jun 2026 17:38:38 +0000

If you've used Next.js in the last couple of years you've probably reached for next/font. It's genuinely great — but I still see custom fonts done in ways that tank the Lighthouse score or make the page jump around on load. Here's how I actually wire up fonts in a Next.js app now, and the one thing that quietly fixes most of the layout shift.

Google fonts: `next/font/google` already self-hosts

First, a thing a lot of people miss: next/font/google doesn't load anything from Google's servers at runtime. At build time Next downloads the font files and serves them from your own origin. So you get the self-hosting win (no third-party request on the critical path) for free:

import { Inter } from "next/font/google";

const inter = Inter({ subsets: ["latin"], display: "swap" });

export default function RootLayout({ children }) {
  return <html className={inter.className}><body>{children}</body></html>;
}

That subsets: ["latin"] line matters — it subsets the file so you're not shipping glyphs for languages you don't use.

Custom / paid fonts: `next/font/local`

For a font that isn't on Google Fonts — a brand font, a freebie you downloaded, whatever — use next/font/local and point it at a WOFF2 in your project:

import localFont from "next/font/local";

const display = localFont({
  src: [
    { path: "./fonts/MyFont-Regular.woff2", weight: "400", style: "normal" },
    { path: "./fonts/MyFont-Bold.woff2",    weight: "700", style: "normal" },
  ],
  display: "swap",
  variable: "--font-display",
});

Then expose it as a CSS variable and use it wherever:

<html className={display.variable}>

.heading { font-family: var(--font-display), sans-serif; }

If your font is a .ttf/.otf, convert it to WOFF2 first — smaller and supported everywhere. I usually just drop it into FontBoxDL's webfont generator (browser-based, no install) and grab the WOFF2 back. And if you're still hunting for the font itself, the free library has a pile of them.

The thing that actually fixes layout shift

Here's the part people skip. Even with display: swap, when the real font swaps in it usually has different metrics than the fallback — so text reflows and your CLS spikes. next/font can fix this automatically if you give it a fallback to match against:

const display = localFont({
  src: "./fonts/MyFont-Regular.woff2",
  display: "swap",
  fallback: ["system-ui", "arial"],
  adjustFontFallback: "Arial", // generates a size-adjusted @font-face for the fallback
});

adjustFontFallback makes Next emit a fallback @font-face with size-adjust/ascent-override tuned so the fallback occupies almost exactly the same space as your real font. The swap becomes nearly invisible. This one prop has done more for my CLS numbers than anything else.

Quick gotchas

Don't import a font inside a component that re-renders. Declare it at module scope (top of the file), once. Importing it in the render path defeats the optimization.
variable vs className: use className if it's your single global font; use variable when you want multiple fonts available as CSS custom properties.
Preload is automatic for fonts used on the route — you don't need a manual <link rel="preload"> like you would in a plain HTML setup.

TL... actually, no TL;DR

Use next/font/google for Google fonts (it self-hosts), next/font/local for everything else, ship WOFF2, and set adjustFontFallback so the swap doesn't shove your layout around. Takes ten minutes and your Core Web Vitals will thank you.

What's your go-to for custom fonts in Next — next/font/local, or do you still hand-roll the @font-face?

I stopped loading fonts from Google's CDN — here's the self-hosting setup that stuck

Zerrin Arslan — Mon, 15 Jun 2026 16:42:33 +0000

For years I just dropped the Google Fonts <link> in my <head> and moved on. One line, done, who cares. Right?

Then I was staring at a Lighthouse report for a landing page that felt sluggish, and there it was in the waterfall: a render-blocking hop to fonts.googleapis.com, then a second one to fonts.gstatic.com for the actual file. Two extra connections — DNS lookup, TLS handshake, the whole dance — before a single character painted. On my laptop? Invisible. On a mid-range Android over flaky mobile data? Very visible.

So I bit the bullet and self-hosted. Took an afternoon, and I've done it on every project since. Here's the setup I've landed on after a bunch of trial and error.

Get a WOFF2 (and only WOFF2)

WOFF2 is supported literally everywhere now and it's ~30% smaller than the old WOFF. You don't need the .ttf, .eot, .svg fallback zoo from 2014 anymore. Just ship WOFF2.

If you've got a .ttf/.otf, convert it with fonttools:

pip install fonttools brotli
fonttools ttLib.woff2 compress MyFont.ttf   # -> MyFont.woff2

Honestly I got tired of doing the CLI thing for one-off fonts, so I ended up building a little browser tool for it — FontBoxDL's webfont generator — drop a TTF/OTF in, get WOFF2 + a @font-face block back, no install. Use whatever's less friction for you.

The @font-face block

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

The line that matters most here is font-display: swap. It tells the browser "show the fallback text immediately, swap in the real font when it arrives." Without it you get FOIT — invisible text while the font loads — which is a worse experience than a quick font flash, basically every time.

Preload the one font that matters

Drop this in your <head>:

<link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>

Two things people get wrong here, me included:

Don't preload everything. Preload only the font(s) you actually use above the fold. If you preload six weights, you've just created a different bottleneck.
Don't forget crossorigin. I once left it off and spent a solid 20 minutes confused about why the font was being downloaded twice. Fonts are always fetched in CORS mode, so the preload has to match or the browser throws your preloaded copy away.

Subset if you care about bytes

A full font ships thousands of glyphs you will never render. If your site is English/Latin, subsetting can knock off 70%+:

pyftsubset MyFont.ttf \
  --unicodes="U+0000-00FF" \
  --flavor=woff2 \
  --output-file=myfont.subset.woff2

I don't always bother for a single light body font, but for display/heading fonts it's an easy win.

Cache it like it'll never change (because it won't)

Fingerprint the filename, then cache forever:

Cache-Control: public, max-age=31536000, immutable

Don't skip the fallback stack

Even with swap, give it a real fallback so the first paint looks intentional and the layout doesn't lurch when the swap happens:

body {
  font-family: "MyFont", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
}

That's the whole thing. Convert → @font-face with swap → preload the critical one (with crossorigin!) → cache hard. It's maybe an hour of work and you get a real LCP/CLS improvement plus one fewer third party in your critical path.

Anyone still on the Google CDN <link> for production — what's keeping you there? Genuinely curious if there's a case I'm missing.