DEV Community: ShieldLabs

10 browser fingerprinting techniques explained

Yahor Papou — Wed, 16 Sep 2026 20:50:57 +0000

Browser fingerprinting is the foundation of device intelligence: the way a site recognizes the same visitor without a cookie. Browser fingerprinting techniques are the individual methods a site uses to read attributes of a browser, each one probing a different surface, and combine them into an identifier that recognizes the same visitor again. No single attribute is unique; the power is in the combination. A landmark study by the Electronic Frontier Foundation, published in the 2010 Privacy Enhancing Technologies Symposium proceedings, found that a browser fingerprint carried enough distinguishing detail to single out roughly 84 percent of browsers in its sample.

The toolkit has grown from a handful of HTTP headers to a layered read across the graphics stack, the audio engine, and the network itself. The consistent pattern is that the attributes a browser can fake in JavaScript are the weak ones, and the techniques that reach down to the real hardware and the connection are the ones that hold up under a tool built to defeat them. This guide walks through the main techniques behind browser fingerprinting, what each one reads, and how stable each is.

Key takeaways

A browser fingerprint is built from many techniques at once. Each reads one attribute, and combined they carry enough distinguishing detail to recognize a returning visitor without a cookie.
The strongest techniques read what the browser cannot easily hide: how the device renders graphics (canvas, WebGL), processes audio, and negotiates a connection (TLS, network).
Declared attributes like the user agent are easy to spoof, so they add little on their own. The render-and-hardware techniques are what make a fingerprint stable.
Anti-detect browsers fake these attributes per profile, but faking many layers consistently is hard, so the contradictions between them are their own detection signal.

What are browser fingerprinting techniques?

Browser fingerprinting techniques are the individual methods a website uses to read attributes of a visitor's browser, with each method probing a different surface such as graphics rendering, audio processing, installed fonts, or the network connection. No single attribute is unique on its own, but together they carry enough distinguishing detail to recognize the same browser, and the device behind it, again without a cookie. These are the methods behind browser fingerprinting.

How browser fingerprinting works

Browser fingerprinting works by collecting attributes that vary from one device to the next, then combining them into a single identifier. Each attribute on its own is shared by many people; together they narrow the field until the combination is, in most cases, unique. The detail that makes it work is that much of this data is exposed automatically through standard browser APIs, so a script can read it in milliseconds without any permission prompt.

The techniques split into two families. Declared attributes are values the browser simply reports, like the user agent or the language, and they are trivial to change. Derived attributes are produced by asking the browser or device to do something, render an image, process an audio signal, negotiate a connection, and reading the result. Derived attributes are what give a fingerprint its staying power, because they reflect the real hardware and software underneath rather than a string the user can edit.

The main browser fingerprinting techniques

The techniques below are listed roughly from the most stable to the most easily changed. A real fingerprint reads many of them at once. Most of them run inside the browser, canvas, WebGL, audio, fonts, and the declared attributes, while TLS and WebRTC read the layer underneath, the connection and the network, which is why they are harder to fake and pull double duty for anonymity detection. In practice a detection system reads across all of these together.

Technique	What it reads	How stable
Canvas fingerprinting	A hash of how the device renders text and graphics to a hidden canvas	High
WebGL fingerprinting	The GPU and graphics driver, read from a rendered 3D scene	High
Audio fingerprinting	Tiny differences in how the device's audio stack processes a generated signal	High
TLS fingerprinting (JA3/JA4)	The exact shape of the TLS handshake the browser sends	High
WebRTC	A local or real IP address the browser can expose, even behind a VPN	Medium
Font fingerprinting	Which fonts are installed and how they render	Medium
Hardware attributes	CPU cores, device memory, touch points, sensors	Medium
Media device fingerprinting	How many media devices are connected and of what kind (full labels need camera or mic permission)	Low
Screen, timezone, language	Resolution, color depth, timezone offset, locale	Medium
User agent and client hints	The declared browser, version, and operating system	Low

Canvas fingerprinting

Canvas fingerprinting asks the browser to draw text and shapes to an off-screen HTML canvas, then reads the pixel data back and hashes it. Because the result depends on the GPU, the graphics driver, the operating system's font rendering, and anti-aliasing, two devices almost never produce the same hash. It is one of the most reliable techniques because the user cannot easily change how their hardware renders, which is why canvas fingerprinting carries so much weight in a combined read.

WebGL fingerprinting

WebGL fingerprinting is the 3D cousin of canvas. A script renders a scene through the WebGL API and reads back both the rendered output and the reported GPU vendor and renderer strings. By exposing the graphics hardware directly, WebGL fingerprinting stays stable per device and is hard to spoof convincingly.

Audio fingerprinting

Audio fingerprinting uses the Web Audio API to generate a sound signal, process it through the device's audio stack, and measure the output. The tiny variations introduced by the hardware and the audio processing produce a stable value that differs between devices, even when nothing is actually played out loud. This kind of audio fingerprinting is a different thing from the music recognition that shares the name.

TLS fingerprinting (JA3/JA4)

TLS fingerprinting reads the connection itself rather than anything in the page. When a browser opens an encrypted connection, the order and contents of the TLS handshake it sends are characteristic of the client software. Methods like JA3 and the newer JA4 summarize that handshake into a value, which is powerful because it is sent over the network and a page script cannot rewrite it. It is the technique that most often catches a browser lying about what it is, and the JA4 fingerprint is how that handshake becomes a value you can compare.

To see how far that goes, run browsers configured to spoof their identity through a combined read, and the TLS handshake is the layer that gives them away most reliably. A profile can rewrite its user agent in seconds, but the handshake it actually negotiates still matches the client software underneath, so the declared browser and the connection stop agreeing. JA4, released in 2023, made that handshake easier to reduce to a single comparable value, which is why a contradiction between it and the declared user agent is such a dependable tell.

WebRTC

WebRTC is a browser feature for real-time audio and video, and while setting up a connection it can reveal a local network address, and sometimes the real public one, even when the visitor sits behind a VPN or proxy. That makes it less a source of device distinguishing detail and more a way to notice a connection that is hiding its origin. It is why WebRTC matters more for anonymity detection, surfacing a real address that contradicts the declared one, than for telling two ordinary devices apart.

Font fingerprinting

Font fingerprinting detects which fonts are installed by measuring how sample text renders, since a missing font falls back to a default with different dimensions. The set of installed fonts reflects the operating system and the software a person has added, which makes it a useful medium-stability signal.

Hardware and device attributes

A browser also exposes hardware hints: the number of logical CPU cores, an approximate amount of device memory, the maximum number of simultaneous touch points, and, with permission, motion and orientation sensors. The set of supported browser features and APIs adds a few more bits the same way. Older techniques read the battery level and charging state too, though browsers have since restricted that one specifically because it was being used to track people. None is unique alone, but together they add distinguishing detail and tend to stay constant for a given device.

Media device fingerprinting

Media device fingerprinting reads the list of media inputs and outputs the browser reports through the media devices API: the microphones, cameras, and audio outputs attached to the machine. It captures nothing from them, only how many are connected and of what kind. The full list, with each device's label and ID, is only exposed once the visitor has granted camera or microphone access, so on its own this technique is a weak, supporting signal rather than a primary one. Where it does apply, the set of devices stays fairly consistent for a given machine and is awkward to fake convincingly across a fleet of fake profiles.

Screen, timezone, and language

Screen resolution and color depth, the timezone offset, and the language and locale are all read directly. They are moderately stable and useful mostly as corroboration, and a mismatch between them, a timezone that disagrees with the declared locale, is itself a tell.

User agent and client hints

The user agent string and the newer client hints report the browser, its version, and the operating system. They are the easiest attributes to spoof, so on their own they add almost no distinguishing detail, but when they disagree with what the render and TLS techniques reveal, that disagreement is a detection signal.

How unique and stable is a fingerprint?

A fingerprint's strength comes from distinguishing detail: how much each attribute narrows the field of possible devices. The EFF's early research found most browsers were unique within its sample. In 2018, a study of around two million fingerprints, published in the Web Conference proceedings, found only about 33 percent were unique, because common phone models share very similar fingerprints. The practical reality sits in between: on desktop, a full fingerprint is usually distinctive; on mobile, it is weaker on its own and leans more on the network and behavioral layers.

Stability is the other half. Fingerprints drift as browsers update, drivers change, and fonts are added, so a resilient system does not expect an exact match every time. It scores how much of the fingerprint agrees and tolerates small changes, which is also what separates a returning real user from an assembled profile that is too clean or internally contradictory.

Can browser fingerprinting be blocked?

Browser fingerprinting can be resisted but not fully blocked, and the trade-offs are real. Privacy browsers and extensions add noise to canvas and audio readings, block known scripts, or make a device look like many others, and an anti-detect browser goes further by spoofing a full set of attributes per profile. Each of these changes some surfaces, but covering every technique consistently is hard, and the act of covering them, a too-uniform fingerprint, an injected-noise canvas that changes on every read, or a TLS handshake that disagrees with the declared browser, becomes its own signal. That cat-and-mouse plays out in full when a session runs an anti-detect browser.

How browser fingerprinting works without a cookie

Browser fingerprinting works without a cookie, and that is the point. A cookie is a value the site writes into the browser, so the visitor can clear it, switch to a private window, or move to a fresh browser and the link is gone. A browser fingerprint is not written anywhere; it is derived on the fly from the attributes the techniques above read, so the same browser produces the same identifier on the next visit even after cookies are cleared. That is why it survives the resets a fresh email and a private window are meant to provide.

Fingerprinting does not replace cookies so much as complement them. A first-party cookie is a fast, reliable way to recognize a returning visitor who has not cleared anything, and the fingerprint is the layer underneath that still holds when the cookie is gone. Reading both together gives a steadier recognition than either one alone. That complement matters even though the third-party cookie did not disappear on the timeline many expected: in April 2025, Google confirmed it would not phase out third-party cookies in Chrome after all, keeping its existing cookie-choice approach, so cookieless recognition is a resilient companion to cookies rather than a scramble to replace them.

How browser fingerprinting helps detect fraud

Browser fingerprinting helps detect fraud because most online abuse depends on one person looking like many different people. Multi-accounting, free-trial farming, fake signups, and account takeover all rely on creating a fresh-looking visitor for each attempt, usually by clearing cookies, switching browsers, or rotating IPs. A browser fingerprint cuts through that, because the same device keeps producing the same identifier no matter how many fresh emails and new IPs sit on top of it. Linking those attempts back to one device is what turns a wall of separate-looking accounts into a recognizable pattern.

The combination of techniques is also a fraud signal in its own right. A real browser produces attributes that agree with each other: the declared user agent matches what the render and TLS techniques reveal, the timezone fits the locale, the network looks like a residential connection. A tool built to fake a visitor has to keep all of those layers consistent at once, and the moment they can contradict each other, a TLS handshake that disagrees with the declared browser, a risk signal that surfaces a real address behind a VPN, that disagreement is the tell. So fingerprinting helps detect fraud two ways at once: it links repeat attempts to one device, and it flags the inconsistencies that mark an assembled identity.

Recognizing returning visitors with ShieldLabs

ShieldLabs turns device and browser signals into a stable device identifier through one JavaScript snippet that recognizes a returning visitor even after cleared cookies and a rotated IP. The identifier is derived from the combination of signals, which is what makes it survive the resets a fresh email and a new IP are meant to provide, so your team can link repeat fraud and abuse attempts back to one device.

Around that identifier, each visit returns a risk score from 0 to 100 with the named signals behind it, including the risk signals, a VPN, anonymous proxy, datacenter connection, or anti-detect browser, that surface when what a visitor presents and the underlying signals contradict each other. The API and webhooks deliver the risk score and named risk signals, while four High-Risk Events, multi-accounting, account sharing, impossible travel and account takeover, are detected directly in the analytics dashboard, API and webhooks. Because the read happens in the background from data the browser already exposes, it adds no friction for a real visitor, and ShieldLabs helps block fraudulent and abusive traffic.

Sources

Eckersley, Peter (Electronic Frontier Foundation): How Unique Is Your Web Browser? (PETS, 2010)
Wikipedia: Device fingerprint
MDN Web Docs: Canvas API
Gómez-Boix, Laperdrix, Baudry: Hiding in the Crowd: An Analysis of the Effectiveness of Browser Fingerprinting at Large Scale (WWW, 2018)
Google: The Privacy Sandbox: Next steps (2025)

Free-trial abuse vs API-key abuse vs rate limiting: which layer stops what

Yahor Papou — Wed, 16 Sep 2026 13:58:48 +0000

A self-serve AI product gets a surprise five-figure compute bill, and the incident channel calls it "API abuse." Sometimes that is right. Often the real cause sits one layer upstream, at signup, where one person quietly farmed a hundred free-trial accounts and every one of them minted a valid key. In 2025, Stripe found that AI startups with self-serve sign-ups and direct API access saw 10x more attempted abuse than enterprise AI solutions, and a lot of that pain comes from blaming the wrong layer. Free-trial abuse, API-key abuse, and rate limiting get treated as one thing. They are three problems, on three layers, with three owners, and the fix for one does almost nothing for the others.

Key takeaways

Free-trial abuse is an identity problem at signup: one user opening many accounts to claim free credits. You stop it before a key is ever issued.
API-key abuse is a usage problem after a key exists: a key, often a leaked legitimate one, called at a volume or in a pattern it should not be.
Rate limiting and spend caps are ceilings, not an identity check. They cap any single key, but they do not know that one person is behind a hundred of them.
The layers complement each other. Identity scoring keeps farmed accounts from minting keys; gateway limits contain the damage of any key that slips through or leaks later.
A CAPTCHA gates obvious bots at the form. It does not catch a human operator running many real-looking signups, and it is a different control from device-and-network identity.

The three problems people blame for one bill

These three get conflated because they all end in the same place, a bigger-than-expected bill or a degraded service, but they start in different places. Naming where each one starts is the whole game, because the cheapest fix lives at the layer where the problem begins, not where the symptom shows up.

Free-trial abuse starts at the signup form, before any account or key exists. One user creates many accounts to claim the free credits each new account gets.
API-key abuse starts after a key is issued: a valid key gets shared, leaked, or pointed at the API in a way it was never meant for.
Rate limiting is not a problem at all; it is the gateway control that caps how hard any one key or org can hit you. It contains damage, but it does not identify who is behind the traffic.

Conflating them is how a team ends up with a gap: they tighten rate limits and rotate keys after a bad week, feel safer, and never notice that the farmed accounts minting those keys are still arriving at the front door untouched.

Free-trial abuse vs API-key abuse vs rate limiting at a glance

Here is the boundary in one view. Read down each column to see that these are genuinely different problems, not three names for one.

	Free-trial (signup) abuse	API-key abuse	Rate limiting and spend caps
What it is	One user opens many accounts to claim free credits repeatedly	A key, often a leaked or shared legitimate one, used at the wrong volume or pattern	A ceiling on how many calls or how much spend any one key or org is allowed
When it happens	At signup, before the account or key exists	After a key is issued, during usage	Continuously, as a guardrail on every key
What is behind it	A human (sometimes automated) farming identities; the device repeats while the email and IP rotate	A leaked credential, a scraper, or a legitimate key pushed past its intent	Nothing; it is your own enforcement, not an adversary
The layer	Signup identity	Key usage	Gateway
Who owns the fix	Identity scoring at registration	Key rotation, scoping, per-key monitoring	Your API gateway or proxy
What it costs you if missed	Compute burned across a hundred farmed accounts, plus polluted growth metrics	A single key running away with your budget or exfiltrating data	Without it, one key can drain the whole bill

What is free-trial abuse?

Free-trial abuse is one user creating many accounts to claim the same free offer more than once, scored and stopped at the registration before any credits or keys are provisioned. It hides because the user changes the surface details, a fresh email, a new IP, a cleared cookie, while the device and network behind the accounts repeat. An email check or an IP rule never sees that repetition; reading the device does.

We measured this by rebuilding a signup the way a farmer does, rotating a new email, a fresh IP, and an emptied cookie on each pass, and the device underneath kept pointing at the same identifier every time. The surface details are meant to be disposable; the device is the part that repeats. That gap only widened in 2020, when Safari began blocking third-party cookies by default, leaving a cookie an even weaker anchor for a signup than the device beneath it.

This is the only one of the three layers that is about who is signing up rather than what a key is doing. The advantage is timing: scoring the registration is far cheaper than chasing the compute after a hundred trials are already calling the model. The signals, the credit-gating, and the economics of how to prevent free-trial abuse at an AI company all turn on that timing; the point here is just where it sits: upstream of the key, at identity.

What is API-key abuse?

API-key abuse is a valid key being used at a volume, from a place, or in a pattern it was never meant for, and it lives entirely after the key is issued. The key might be a leaked secret committed to a public repo, a shared credential passed around a team, or a legitimate key repointed at scraping the model's output. Whatever the source, the control surface is the key itself, and the standard moves are the gateway's:

Scope and rotate keys. Short-lived, narrowly scoped keys limit the blast radius of any one that leaks. Broken authentication is one of the most common API risks for a reason, and it is squarely an API-security concern, not a signup one.
Per-key spend caps. A hard ceiling on spend per key and per org means no single credential, abused or not, can run away with your budget. The OWASP API Security Top 10 calls the missing version of this "unrestricted resource consumption."
Anomaly monitoring on usage. Watch for a key whose call volume, geography, or endpoint mix suddenly changes, the signature of a credential that has left its owner's hands.

None of this reads the human at the front door, and it does not need to. API-key abuse is downstream of identity. By the time a key exists, the farmed-account question was already answered, or missed, one layer up.

What is rate limiting (and spend caps)?

Rate limiting caps how many requests a key or org can make in a window, and spend caps cap how much it can cost; both are essential guardrails, and neither knows who is behind the traffic. They are about volume, not identity. A rate limiter will happily throttle one key at a thousand requests a minute, which is exactly what you want when a single credential goes rogue.

The gap is structural: a rate limit applies per key. The free-trial farmer's whole technique is to spread the load across a hundred keys, each one comfortably under the limit. A hundred accounts each making polite, well-behaved calls is invisible to a per-key ceiling, because no individual key ever misbehaves. Spend caps have the same blind spot. They stop one key from draining the budget; they do nothing about a hundred keys each spending a small, allowed amount that sums to the same loss. Rate limiting contains the runaway-key problem and leaves the farmed-account problem completely open. That is not a flaw in rate limiting; it is just a different layer.

Where CAPTCHA and bot-gating fit

A CAPTCHA sits at the signup form and tries to separate humans from scripts, which makes it a bot control, not an identity one. It raises the cost of fully automated, headless signup floods, and for that narrow job it helps. Two things it does not do: it does not stop a human operator, or a lightly automated one driving a real browser, from completing many real-looking signups, and it does not tell you that two solved-CAPTCHA signups trace back to one machine. CAPTCHA asks "is this a bot?"; the identity layer asks "have we seen this device before?". They answer different questions, and a serious farming operation passes the first while failing the second.

Which layer stops what: the honest map

Put together, the picture is simple and the layers do not substitute for each other:

Signup identity catches the farmed account before a key is minted. It is the cheapest place to act, because nothing has been provisioned yet.
Key scoping, rotation, and monitoring contain a key after it exists, whether it was farmed past the identity layer or leaked later.
Rate limits and spend caps are the backstop that keeps any single key, abused or not, from running away with the bill.
CAPTCHA thins out crude automation at the form, and leaves the human-operated farm for the identity layer.

A team that only hardens the gateway, more rate limits, tighter key scopes, is defending the second and third layers while the first stays open. A team that only scores signups stops the farm but still needs ceilings for the key that leaks next week. The two halves are complementary by design.

Where ShieldLabs fits, and where it does not

ShieldLabs reads exactly one of these layers: the signup-identity one. You add a JavaScript snippet to your signup or trial-activation page, and on the first visit it returns a risk score from 0 to 100 with the risk signals and persistent identification behind it, before a single credit or key is provisioned. When a "new" signup traces back to a device you have already seen, that linkage is the farmed-account tell a fresh email is meant to hide.

To be plain about scope: ShieldLabs scores the signup on a 0 to 100 risk score, names the risk signals that fired, and directly detects multi-accounting, so your team can keep farmed accounts from minting keys in the first place and the layer downstream has less to contain. Key usage monitoring, secret rotation, and spend-cap enforcement are your gateway's job, and they should stay there. You read the risk score and named risk signals through the API and webhooks and decide, by your own rules, whether to gate credits, ask for a verification step, or let a clean signup through. It complements the gateway. The same identity layer carries into new-account fraud prevention and free-trial abuse prevention.

Ready to close the signup-identity gap?

Install the ShieldLabs JavaScript snippet and risk-score every trial signup for linked accounts and risk signals in about five minutes, free for the first 5,000 identifications.

Start Free

Originally published on the ShieldLabs blog.