Font enumeration and how detection tools build a font fingerprint
Font enumeration and how detection tools build a font fingerprint
Most people assume a website only knows what you tell it. fill in a form, hand over an email address, done. the reality is messier. before you’ve clicked anything, the page can already be building a profile of your device, and one of the quieter signals feeding that profile is the list of fonts installed on your machine.
font enumeration is the process by which a script probes your system to discover which typefaces are present. on its own that sounds harmless, “who cares if a website knows I have Arial?” but when you combine a font list with a dozen other signals, you get a fingerprint that can identify a device across sessions, across browsers, and across IP addresses. if you’re running accounts at scale, managing airdrop wallets, or doing any kind of multi-session work, understanding this mechanism is non-negotiable. you can read a broader treatment of how these signals stack up on the antidetect review blog, but this piece focuses specifically on fonts.
what it is
font fingerprinting is a browser fingerprinting technique that identifies a device by the set of fonts installed on its operating system. two machines running the same browser version on the same OS can still produce different font lists because one user installed Adobe Creative Suite, or Office 365, or a CJK language pack, or any number of software products that bundle custom typefaces.
the output is not a readable list in the traditional sense. detection systems hash the font set, or combine it with other attributes, into a compact identifier that persists as long as your font configuration stays the same. change nothing, and your font fingerprint follows you across incognito tabs, VPNs, and proxy rotations.
the EFF’s Cover Your Tracks tool is the easiest way to see this in action. it shows you in plain language how unique your browser is against their test dataset, and font data is one of the contributing attributes.
how it works
there are two main mechanisms, and both run without any user prompt in most browsers.
the canvas/CSS timing method is the classic approach. javascript draws text using a target font name (say, “Calibri”) and falls back to a generic family (“sans-serif”). it then measures the rendered dimensions of that text using the Canvas API or CSS layout. if Calibri is installed, the measurement reflects Calibri’s actual glyph metrics. if it isn’t, the measurement reflects the fallback font. the script repeats this for a list of hundreds of fonts, sometimes over a thousand, and records which ones produce non-fallback measurements.
the MDN documentation on queryLocalFonts() covers the newer explicit API, which Chrome 103 and later support. this method directly enumerates installed fonts and returns metadata including PostScript names and full family names. it requires a user permission grant, so it’s mostly used in design applications and web-based creative tools, not in silent fingerprinting scripts. the canvas method requires no permission at all.
the process is fast. a competent implementation can probe a list of 600 fonts in under 200 milliseconds. the result is typically hashed, then combined with other signals like screen resolution, timezone, WebGL renderer, and audio context fingerprint to produce a composite device ID.
fingerprinting SDKs like FingerprintJS (now Fingerprint Pro) document their methodology to a degree. their published research notes that font enumeration contributes meaningfully to fingerprint stability because font sets change infrequently on most machines. a person might clear cookies weekly, but they’re unlikely to install or remove typefaces unless they’re doing it deliberately as part of a spoofing workflow.
why it matters
cross-session linking. cookies can be cleared. localStorage can be wiped. but your font set persists across all of that. a platform running a persistent fingerprinting layer can link a new session to a previous banned account even when the user has changed their IP, cleared all storage, and opened a fresh browser profile. this is why cookie-clearing alone does not constitute a real separation between accounts.
multi-account detection at scale. when two accounts share the same font fingerprint, fraud systems flag them as the same device. this applies to e-commerce platforms enforcing single-account policies, ad networks checking for click fraud, and token-generation platforms running sybil resistance. font overlap is a cheap, passive check, and it runs on every page load.
antidetect browser effectiveness depends on it. tools like Multilogin, AdsPower, and GoLogin each handle font fingerprinting differently. some inject a fixed fake font list per profile. some use the real list but randomize measurement noise. understanding the mechanism tells you what to look for when evaluating a product. if a tool doesn’t address canvas-based font probing, its profile isolation is weaker than advertised. the multiaccountops.com blog covers how different antidetect stacks handle this in operational contexts, including which tools hold up under Fingerprint Pro checks.
it’s passive and silent. unlike device permissions or login prompts, font enumeration triggers no browser warning. the user sees nothing. this asymmetry matters if you’re thinking about detection from either side, either trying to evade it or trying to understand what data a platform is collecting about you.
common misconceptions
“incognito mode blocks font fingerprinting.” it doesn’t. incognito mode prevents storage of cookies and browser history on disk after the session ends. it does not restrict javascript execution, canvas access, or CSS rendering. a fingerprinting script runs identically in incognito versus a normal tab. your font list is just as readable.
“a VPN changes my fingerprint.” a VPN masks your IP address. it does nothing to the software environment of your browser. font enumeration happens inside the browser process, entirely independent of network routing. two sessions originating from the same machine via different VPN endpoints will still produce the same font fingerprint.
“using a common browser is enough.” the logic here is that if everyone uses Chrome on Windows, the fonts will all be similar and fingerprinting won’t discriminate. this is partially true but overstated. yes, a minimal Windows 11 install has a predictable default font set. but any deviation from that baseline, one extra language pack, one design tool, one corporate font bundle, makes your profile more unique. research by Peter Eckersley at the EFF, published in the paper How Unique Is Your Web Browser?, demonstrated that a significant fraction of browsers are unique or near-unique even before exotic attributes are factored in.
“blocking javascript stops font fingerprinting.” blocking JS would stop canvas-based font probing. but it also breaks almost every modern site, which makes it impractical as a general defence. more importantly, some server-side fingerprinting layers collect signals through the rendering pipeline itself, not purely through client-side scripts. and CSS-based font detection requires no scripting at all, just a stylesheet that loads different resources depending on whether a font renders at a certain width. going full no-JS is not a realistic operating posture for most use cases.
where to go from here
font enumeration is one piece of a larger fingerprinting puzzle. once you understand how this vector works, the natural next topics are:
canvas fingerprinting, which is closely related because the canvas API is also the primary delivery mechanism for font probing. our guide canvas fingerprinting and what it reveals about your browser covers the full mechanism including audio fingerprinting, which uses a similar approach.
WebGL fingerprinting, which pulls GPU model and driver information and is often combined with font data in composite IDs. the article WebGL fingerprinting: how GPU data feeds browser tracking is a good follow-on read.
antidetect browser evaluation, specifically how to test whether a tool is genuinely spoofing your font list versus just claiming to. the how to test your antidetect browser against Fingerprint Pro walkthrough covers this with specific testing steps.
proxy-side vs. browser-side separation, because even solid font spoofing fails if your proxy setup creates other correlation points. residential proxies and datacenter proxies carry different risk profiles at the fingerprinting layer, and understanding which to pair with which antidetect tool matters. the proxyscraping.org blog has practical coverage of proxy types from an operational standpoint.
the underlying takeaway is straightforward: font fingerprinting is not a theoretical concern. it runs on most major platforms today, it requires no permissions, and it survives most naive evasion attempts. knowing how it works is the starting point for knowing how to operate cleanly.
Written by Xavier Fok
disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.