Font fingerprinting | ScrapeRouter

Font fingerprinting is a browser identification technique that checks which fonts are available on a device and how text renders with them. Anti-bot systems use it as one signal in a larger fingerprint because the font set and rendering behavior often differ across operating systems, browsers, and automation setups.

Examples

A common implementation is simple: the page draws text with different font families, measures the size, and compares the result to fallback fonts. If the dimensions change, that font is probably installed.

function detectFont(font) {
  const text = "mmmmmmmmmmlli";
  const size = "72px";
  const baseFonts = ["monospace", "sans-serif", "serif"];

  const canvas = document.createElement("canvas");
  const ctx = canvas.getContext("2d");

  function measure(fontFamily) {
    ctx.font = `${size} ${fontFamily}`;
    return ctx.measureText(text).width;
  }

  return baseFonts.some(base => {
    const baseWidth = measure(base);
    const testWidth = measure(`'${font}', ${base}`);
    return testWidth !== baseWidth;
  });
}

console.log(detectFont("Arial"));
console.log(detectFont("Helvetica"));

In scraping, the problem is not just whether a single font exists. The bigger issue is that a Linux headless browser with a thin font package often exposes a very different environment from a normal user machine, and that mismatch gets folded into a broader fingerprint score.

Practical tips

Don't treat font fingerprinting as a standalone block reason: it is one signal among many, alongside canvas, WebGL, navigator properties, screen data, timezone, and headers.
If you run headless browsers in containers, pay attention to installed font packages: a bare container with almost no fonts is easy to spot.
Keep the OS, browser version, locale, and font stack consistent: randomizing one layer while leaving the rest obviously fake often makes things worse.
Test against real target pages, not fingerprint demo sites only: production bot defenses combine signals differently.
If you use a scraping API or browser layer, check whether it normalizes the browser fingerprint: this is exactly the kind of low-level maintenance teams waste time on.
Be careful with custom browser patching: fixing fonts while canvas, WebGL, and client hints still disagree does not solve much.

A rough Linux setup might include installing common font packages before launching automation:

apt-get update && apt-get install -y \
  fonts-dejavu \
  fonts-liberation \
  fonts-freefont-ttf \
  fontconfig

If you are scraping through ScrapeRouter, this is the kind of browser-environment problem you generally want abstracted away instead of hand-tuning per target.

Use cases

Bot detection: security systems use font availability and text measurement differences to help distinguish real user environments from automation.
Browser fingerprinting research: teams test how much entropy installed fonts add when combined with other signals.
Scraper hardening: engineers compare headless environments against real browsers to find obvious gaps causing silent blocks.
Managed browser infrastructure: routing scraping traffic through a system that maintains realistic browser profiles reduces the need to debug font-level mismatches by hand.