Font Fingerprinting: Detecting Installed Fonts

The set of fonts installed on a machine is a surprisingly personal thing. Operating system version, office suites, design tools, language packs, printer drivers, and games all drop fonts onto disk. No browser exposes a direct “list my fonts” API, yet the fonts a device carries leak through the very act of drawing text. That leak is the basis of font fingerprinting.

This article walks through the mechanics: how a page infers which fonts exist without an enumeration API, why the resulting list carries real entropy, where the technique breaks, and how to fold it into a broader device-intelligence signal without over-relying on it.

Why the font list is high-entropy

Entropy measures how much a signal narrows down the population of devices. A signal that splits users into two equal halves carries one bit; the font list, in practice, carries many more because installed fonts vary along several independent axes.

• Platform baseline. Windows, macOS, Linux, iOS, and Android ship different default font families. Segoe UI implies Windows; San Francisco and Helvetica Neue variants imply Apple platforms.
• Bundled software. Microsoft Office installs Calibri, Cambria, and a large cluster of fonts. Adobe tools add their own. The presence or absence of these clusters partitions users sharply.
• Locale and language packs. CJK, Cyrillic, Arabic, and Indic font families appear when users install language support, correlating with region and usage.
• User-installed fonts. Designers and developers accumulate long tails of custom typefaces that few others share.

For background on how signals combine to distinguish devices, see browser fingerprinting entropy explained. Fonts are one contributor among many in a device fingerprinting pipeline.

Detection without an enumeration API

Browsers deliberately do not expose a raw font list. The classic workaround measures rendered text. The idea: render a string in a candidate font with a fallback baseline font, then compare the pixel dimensions. If the candidate is installed, the glyph metrics differ from the fallback; if it is missing, the browser substitutes the fallback and the metrics match.

The standard approach uses three generic baselines — monospace, sans-serif, and serif — because a font that changes dimensions against all three is very likely genuinely present.

function isFontInstalled(font) {
  const baselines = ['monospace', 'sans-serif', 'serif'];
  const testString = 'mmmmmmmmmmlli';
  const testSize = '72px';
  const span = document.createElement('span');
  span.style.position = 'absolute';
  span.style.left = '-9999px';
  span.style.fontSize = testSize;
  span.textContent = testString;
  document.body.appendChild(span);

  const detected = baselines.some((base) => {
    span.style.fontFamily = base;
    const baseW = span.offsetWidth, baseH = span.offsetHeight;
    span.style.fontFamily = `'${font}', ${base}`;
    return span.offsetWidth !== baseW || span.offsetHeight !== baseH;
  });

  document.body.removeChild(span);
  return detected;
}

A more modern variant uses the Canvas measureText API, which returns advance widths and, in newer browsers, richer TextMetrics such as bounding-box ascent and descent. Canvas measurement is faster than DOM reflow and less visible in the layout tree. It pairs naturally with canvas fingerprinting, which reads rasterization differences from the same drawing surface.

The FontFace and local-font surfaces

Two newer platform features change the picture. The FontFaceSet API lets a page ask document.fonts.check('72px "Some Font"'), giving a cleaner presence test than pixel measurement. It is convenient but still limited to probing named candidates rather than enumerating.

The queryLocalFonts() method from the Local Font Access API can return the actual installed list, including PostScript names, but it is permission-gated and only surfaces after an explicit user grant in supporting browsers. Because it requires consent and has narrow availability, it is not a covert fingerprinting vector; it is more relevant to design tools than to fraud signals.

Technique	Enumerates directly	Needs permission	Notes
DOM metric measurement	No	No	Probes a candidate list; slow via reflow
Canvas measureText	No	No	Faster; richer metrics on modern browsers
FontFaceSet.check	No	No	Clean presence test for named fonts
queryLocalFonts	Yes	Yes	Explicit grant; limited browser support

Where the technique breaks

Font fingerprinting is not a silver bullet, and treating it as one produces false confidence.

• Probe-list dependence. Metric-based detection only finds fonts you name in advance. A well-chosen list of a few hundred common fonts captures most of the signal, but exotic fonts outside the list stay invisible.
• Anti-fingerprinting defenses. The Tor Browser ships a fixed font set and blocks metric probing; Safari and Firefox restrict enumeration to system fonts and add measurement noise. These deliberately flatten the signal.
• Rendering variance. Sub-pixel rendering, zoom level, and DPI can shift metrics, so a naive equality check needs tolerance to avoid false negatives.
• Convergence over time. As browsers move toward a fixed system-font set exposed to web content, the long tail of user-installed fonts becomes harder to read. Treat font entropy as a declining resource, not a constant.

Because of this, a font list should never be a standalone identifier. It is a contributor to a confidence score, reinforced by TLS, canvas, audio, and behavioral signals.

Using fonts responsibly in device intelligence

The engineering goal is a stable, privacy-respecting visitor ID, not maximal surveillance. A few practices keep font signals useful and defensible.

• Hash, do not store raw lists. Reduce the detected set to a stable hash server-side so you retain matching power without warehousing a readable inventory of someone’s software. This aligns with data minimization for fraud signals.
• Weight it correctly. Give fonts a moderate weight in the aggregate. A single missing or extra font should nudge, not flip, an identity decision.
• Combine with server-side signals. Client font data is spoofable; pair it with TLS fingerprinting with JA4, which an attacker cannot easily forge from JavaScript.
• Respect signals of intent. Honor Global Privacy Control and jurisdictional rules; see GDPR device fingerprinting for the compliance framing.

In Prynt, font detection feeds the same client agent that gathers other browser signals, and the raw values never leave the device unhashed. You can watch the signal behave in the playground and read the integration details in the docs.

Frequently asked questions

Can font fingerprinting run without any special permissions?

Yes. Measuring text dimensions with the standard DOM or Canvas APIs needs no permission prompt, which is exactly why the technique is both powerful and worth handling carefully. The permission-gated queryLocalFonts() is the exception, and it is not the method used for covert fingerprinting.

Does installing the same fonts on two machines make them identical?

No. Font lists narrow the population but rarely isolate a device alone, so they are combined with canvas, WebGL, and other signals to reach a stable visitor ID. Two machines with identical fonts will still differ in rendering, TLS, and hardware signals.

Is font fingerprinting becoming less effective?

Gradually, yes. Browser vendors are restricting enumeration and moving toward fixed system-font sets exposed to web content, which shrinks the long tail of custom fonts. It remains a useful contributor today but should be weighted as a declining source of entropy.

Font fingerprinting turns an ordinary rendering side effect into a meaningful identity signal, and it does so with no permission prompt and little code. The right posture is to treat it as one moderate-weight input in a layered model, hash what you collect, and lean on harder-to-spoof server signals for the decisions that matter. Explore how these signals combine across SDKs and where fonts fit in the wider glossary.