DEV Community: Yahor Papou

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.

JA4 fingerprinting explained: how it improves on JA3, and what it actually identifies

Yahor Papou — Tue, 15 Sep 2026 13:03:29 +0000

JA4 fingerprinting identifies the software behind a connection, a browser, a script, or an automation tool, by reading the TLS Client Hello it sends and condensing that handshake into a short, readable string. It is FoxIO's 2023 successor to JA3, and it exists for one reason: JA3 stopped working. JA3, the old way of fingerprinting a TLS client, broke when the browsers it watched started shuffling their own handshake. After Chrome began randomizing the order of its TLS extensions in 2023, JA3, which hashed those extensions in the order they arrived, produced a different value on almost every connection, so the fingerprint that was supposed to recognize a client recognized nothing. JA4, released the same year by FoxIO, is the answer: it sorts the values instead of trusting their order, stays human-readable, and covers more than just TLS. This guide explains what JA4 is, how it improves on JA3, and the part most write-ups skip, what it actually identifies and what it does not.

Key takeaways

JA4 is a network fingerprint that identifies the software stack behind a connection, a browser, a script, or a tool, from the TLS Client Hello it sends, before any page code runs.
It replaced JA3 because JA3 was order-sensitive: once browsers randomized their TLS extension order, JA3's hash changed on every connection. JA4 sorts the values, so reordering no longer breaks the match.
A JA4 fingerprint is readable, not just a hash. Its parts spell out the TLS version, the cipher and extension makeup, and the application protocol, and JA4 is one of a family (JA4+) that also covers HTTP, TCP, and the server side.
JA4 identifies a client type, not a person or a unique device. Everyone on the same browser and operating system can share one JA4, so it is a corroborating signal, never an identifier on its own.
In fraud detection its value is the contradiction: a request that claims to be one browser but whose JA4 says it is a script or a tool is the tell, read at the network layer.

What is JA4 fingerprinting?

JA4 fingerprinting is a method of identifying the software behind a connection by reading the TLS Client Hello, the first, unencrypted message a client sends when it opens a secure connection, and condensing its characteristics into a short, standardized string. Because different software, a Chrome browser, a Python script, a Go HTTP library, builds that handshake differently, the resulting JA4 string is characteristic of the client type that produced it. It is the successor to JA3, created by FoxIO, the firm founded by JA3's original author John Althouse, and published as an open specification, and it sits at the network and transport layer rather than in the browser. It is the JA4 piece of TLS fingerprinting more broadly.

The reason it reads the Client Hello is that this message is sent in the clear, before encryption begins, so a server can fingerprint the client without decrypting anything. What the fingerprint captures is configuration, the TLS version offered, the list of cipher suites, the extensions, and the application protocols, which together form a signature of the software, not the user.

How JA4 improves on JA3

JA3, introduced in 2017 by John Althouse and colleagues at Salesforce, hashed the Client Hello fields in the exact order the client sent them and reduced the result to a single opaque value. That worked until the order stopped being stable. When browsers began permuting their TLS extensions on purpose, a change Chrome rolled out in 2023, the same browser produced a different JA3 on every connection, and the fingerprint collapsed. JA4 fixes this by sorting the values before it builds the fingerprint, so a harmless reordering produces the same JA4. It also keeps the fingerprint readable instead of hashing everything into one blob, and it extends beyond TLS into a whole family of fingerprints. The differences at a glance:

	JA3	JA4
Introduced	2017	2023
Output	one opaque MD5 hash	a readable, multi-part string
Extension order	order-sensitive, breaks on reordering	sorts the values, survives reordering
Readability	none, just a hash	parts you can read (TLS version, cipher and extension counts, ALPN)
Scope	the TLS client only	a suite covering TLS, the server, HTTP, TCP, and more

The practical upshot is resilience. JA3 was easy to defeat by accident, every browser that randomized its handshake broke it, and easy to defeat on purpose. JA4 raises the bar on both, which is why detection tooling moved to it.

The JA4 string format

A JA4 fingerprint is written in readable parts, often shown as a_b_c, in a compact multi-part shape (the two trailing hashes are 12 characters each, while the readable first part varies). Each part answers a different question:

Part a captures the protocol and transport, the TLS version, whether the connection is over TCP or QUIC, the presence of a server name, and the application protocol negotiated via ALPN (Application-Layer Protocol Negotiation), so t13 reads as TLS 1.3.
Part b summarizes the cipher suites the client offered, as a count plus a sorted hash, so reordering the same ciphers does not change it.
Part c does the same for the extensions and the signature algorithms.

A complete JA4 looks like t13d1516h2_8daaf6152771_02713d6af862: the t13d reads as TLS 1.3 over TCP with a server name present, the digits 1516 count the offered cipher suites (15) and extensions (16), h2 is the negotiated HTTP/2 preference, and the two trailing blocks are the sorted cipher and extension hashes. JA4 also ignores GREASE values, the deliberately random entries a browser adds to its handshake to keep the protocol extensible (defined in RFC 8701), so that padding never shifts the fingerprint.

Because the parts are separate and legible, an analyst can match on the whole string or on a single segment, and can read roughly what a client is from the fingerprint alone rather than looking it up in a table. Because a JA4 is readable and portable, common fingerprints are catalogued in open databases such as JA4DB and can be read directly in tools like Wireshark, so a value seen in your logs can be identified rather than reverse-engineered.

The JA4+ suite: more than TLS

JA4 is the TLS-client member of a larger family called JA4+, a set of fingerprints for different layers of a connection. The ones that come up most:

JA4 fingerprints the TLS client from its Client Hello.
JA4S fingerprints the server's response, the Server Hello.
JA4H fingerprints the HTTP request, including the order of headers and the presence of things like an Accept-Language.
JA4T fingerprints the TCP characteristics, such as window size, which can hint at the operating system or a proxy in the path.
JA4X fingerprints an X.509 certificate, and JA4SSH covers SSH sessions.

Read together, the suite describes a connection from several angles at once, which is what makes a contradiction between layers, a TLS stack that does not match the HTTP behavior, so informative. Recent research pushes the same multi-layer idea further: a 2026 arXiv preprint, On the Internet, Nobody Knows You're an LLM Bot, combines network, HTTP, and browser-level fingerprints to unmask automated web agents, exactly the kind of cross-layer read where a transport-layer fingerprint that disagrees with the browser above it becomes the tell.

What JA4 can and cannot tell you

This is the part that matters most and is the easiest to get wrong. A JA4 fingerprint identifies a client's software stack, not a person and not a unique device. Everyone running the same browser version on the same operating system tends to produce the same JA4, so the fingerprint groups clients by type rather than singling anyone out. It is explicitly not designed to be unique, and there are real edge cases where it is not even stable for one client: Safari, for instance, can reuse a prior session through a TLS extension and present a different fingerprint on the next connection.

That is not a flaw to hide; it is the right way to use the signal. JA4 tells you what kind of client is connecting, with high confidence and almost no cost, and it tells you that server-side before a single line of page code runs. What it does not do is tell you who the visitor is or pin them to one machine. Treated as a corroborating signal rather than an identifier, it is genuinely useful. Treated as a unique ID, it produces false matches and misses.

JA4 in fraud detection

For threat hunters and web application firewalls, JA4 is mostly about grouping malicious traffic and rate-limiting clients that rotate IPs. For fraud and abuse detection the more useful read is narrower: the contradiction between what a client claims to be and what its JA4 says it is. A request can set a user-agent header that says Chrome on Windows, but the user-agent is just a string the client chooses, while the JA4 is produced by the actual TLS library underneath. When the header says one thing and the TLS stack says a scripting library or an automation framework, the mismatch is hard to fake and easy to read. A missing or unusual application protocol value, where a real browser would normally negotiate HTTP/2, points the same way. The reverse holds too: dedicated TLS-impersonation tools can forge a JA4 that matches a real browser, so a clean, matching fingerprint is not proof of a genuine client, only the absence of an obvious mismatch, which is one more reason to read JA4 as corroboration rather than identity.

In testing, we ran requests that set a user-agent header claiming Chrome on Windows and the network layer disagreed: the TLS stack underneath matched a scripting library or automation framework, not the browser named in the header. The header is a string the client picks; the JA4 is produced by the library actually opening the connection, which is far harder to align. This gap became more useful in 2023, when Chrome began randomizing its TLS extension order and JA4's sorted, readable format kept the fingerprint stable through the change.

That makes JA4 a strong corroborating signal for automated abuse and for anti-detect browser setups, which spoof the browser-side fingerprint but often miss the transport layer underneath. It is read alongside the rest of the session rather than acted on alone, because a shared JA4 is normal: the goal is to catch the session whose layers disagree, not to treat a common fingerprint as guilt.

Detecting spoofed clients with ShieldLabs

ShieldLabs reads network signals as one input among many, never as a standalone verdict. The network signals behind a request are cross-checked against the declared browser, the risk signals on the connection, and the rest of the session, so a client whose network layer disagrees with what it claims to be raises the read rather than passing on a header alone.

ShieldLabs scores the session, the device, and the network, and names the signals behind a risk score from 0 to 100. You read that score and the named signals through the API and webhooks and decide, by your own rules, what a contradiction is worth. The broader technique behind these signals is covered in TLS fingerprinting and the wider set of browser fingerprinting techniques.

Sources

FoxIO: JA4+ Network Fingerprinting specification
Amazon Web Services: JA4Fingerprint (AWS WAF reference)
IETF: RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
IETF: RFC 8701: Applying GREASE to TLS Extensibility
Fayolle, Bouhenniche, Pélissier, Laperdrix, Maurice, Rudametkin: On the Internet, Nobody Knows You're an LLM Bot: Unmasking Web Agents with Multi-Layer Fingerprinting (arXiv preprint, 2026)
Wikipedia: Transport Layer Security

FAQ

What is a JA4 fingerprint?

A JA4 fingerprint is a short, readable string that identifies the software stack behind a connection, derived from the TLS Client Hello a client sends when it opens a secure connection. Because a browser, a script, and a tool each build that handshake differently, the JA4 string is characteristic of the client type. It is created by FoxIO as the successor to JA3 and is written in a compact, multi-part format that a person can read directly.

Is JA4 better than JA3?

For most purposes, yes. JA3 hashed the TLS Client Hello in the order the client sent it, so once browsers began randomizing their extension order, the same browser produced a different JA3 on every connection and the fingerprint stopped working. JA4 sorts the values before fingerprinting, so reordering does not break it, and it is human-readable and covers more protocols. JA3 still appears in older tooling, but JA4 is the more resilient successor.

Is a JA4 fingerprint unique?

No. A JA4 fingerprint identifies a client's software stack, not an individual device or person, so everyone using the same browser version and operating system tends to share the same JA4. Some clients are not even stable across connections, for example Safari can present a different fingerprint when it reuses a prior TLS session. That is why JA4 is best used as a corroborating signal weighed with others, not as a unique identifier.

What is the difference between JA3 and JA4?

JA3 produces a single opaque hash of the TLS Client Hello in the order it arrived, which made it break when clients reordered their extensions. JA4 produces a readable, multi-part string and sorts the values so reordering does not change it, and it is part of the JA4+ family that also fingerprints HTTP, TCP, and the server side. In short, JA4 is more resilient, more readable, and broader in scope than JA3.

How does ShieldLabs use network signals?

ShieldLabs reads network signals as one input among many. They are cross-checked against the declared browser and the rest of the session and folded into a risk score, never acted on as a standalone verdict. ShieldLabs scores the session and hands the result to your own rules, and the free tier covers your first 5,000 identifications.

Originally published on the ShieldLabs blog.

Residential proxy detection: why home IPs are the hardest to catch, and how detection actually works

Yahor Papou — Tue, 15 Sep 2026 13:03:19 +0000

A residential proxy hands an attacker a real home IP address, with a clean reputation, in the right city, that can change on every single request. Every defense built around the address itself, reputation lists, datacenter ranges, the old rule of one IP per account, quietly waves it through. That is what makes residential proxies the hardest masked traffic to catch, and it is also the clue to catching them: residential proxy detection is not an IP problem at all. This guide explains what a residential proxy is, where the home IPs actually come from, why IP-based checks miss them, and how detection works when the address is no help.

Key takeaways

A residential proxy routes traffic through a real ISP-assigned home IP, so to a website it looks like an ordinary customer rather than an intermediary.
The home IPs are sourced from real consumer devices, usually enrolled through bundled apps, bandwidth-sharing schemes, or compromised hardware, often without the owner paying attention.
Because the address is a genuine home connection, IP reputation, blocklists, and ASN checks, the tools that catch datacenter proxies, mostly fail on residential ones.
Detection works by reading everything except the address: rapid IP rotation, many accounts behind one home gateway, the device that stays the same as the IPs change, and network contradictions like a datacenter TLS stack or a leaked real IP.
Residential proxies are the hardest case, so no single signal is reliable. Detection corroborates several, treats a contradiction as a risk signal rather than proof, and leaves the decision to you.

What is a residential proxy?

A residential proxy is an intermediary that routes a user's traffic through an IP address that a consumer Internet Service Provider assigned to a real home. Because the request arrives from a genuine household connection, the destination site sees the homeowner's ISP and location instead of the real visitor, so the traffic blends in as an ordinary customer. That is the whole appeal, and the whole problem.

Residential proxies split into a few forms. Rotating proxies swap the exit IP on a timer or on every request, cycling through a large pool of home addresses. Static residential, sometimes sold as ISP proxies, keep one home IP for a longer stretch when an operation needs a consistent identity. They sit at one end of a spectrum: a datacenter proxy uses an obvious hosting address, a mobile proxy uses a carrier IP shared by many subscribers, and a residential proxy uses the hardest-to-question address of all, a real home. A VPN, by comparison, routes everyone through a shared set of provider IP ranges that are far easier to recognize, which is part of why residential proxies have become a preferred choice when an actor wants to stay invisible. Residential proxies are, in short, the hardest class of anonymous proxy to detect.

Where residential proxy IPs come from

A residential proxy is only worth anything because its address belongs to a real household, so the networks selling them need a constant supply of real home connections to route through. In these networks, the exit node is rarely a server in a rack; it is someone's phone, laptop, or smart TV, enrolled through an app they installed for something else. That supply gets built in a few ways, most of them without the owner paying attention:

Bundled SDKs in ordinary apps. A normal-looking app, a game, a messenger, a screensaver, a "free" VPN, ships an embedded component that turns the device into an exit node in the background. Consent is usually buried in a privacy policy, and some of these run whether or not the screen is even on.
Bandwidth-sharing schemes. Apps that openly pay people a few dollars to share unused bandwidth, which in practice rents out the home connection as an exit node for whoever buys the pool.
Compromised consumer hardware. Routers, IP cameras, and smart TVs left on default passwords or outdated firmware get quietly enrolled into a relay network, the owner noticing nothing beyond an occasional slowdown.

Two consequences follow. First, the address carries genuine residential reputation, because it is a genuine residence, which is exactly why blocking one is risky and why the household behind it has no idea it is being used. Second, the pools are cheap, rented, and resold, so the set of addresses you flagged last week is a different set this week. A measurement study characterizing residential proxies, published on arXiv, describes exactly this churn, and it is why a static list never keeps up. Bitsight research in 2026 mapped more than 53 million unique residential-proxy exit IPs, with many overlapping known malware infections, a reminder of how much of this supply comes from compromised consumer devices.

Why residential proxies are so hard to detect

The methods that catch a datacenter proxy all lean on the address, and the address is the one thing a residential proxy gets right. A hosting range announces itself: its autonomous system number belongs to a cloud provider, its IP reputation is often already poor, and a blocklist can catch it. A residential exit defeats all three at once. The address belongs to a consumer ISP, so the ASN looks ordinary. It is a real home connection with no abuse history of its own, so its reputation is clean. And it rotates, so any list you build is stale before you finish it, and the old assumption that one IP means one person breaks completely.

This is why a consumer-looking IP is not, by itself, a reason to trust a session, and why residential proxy detection cannot live on the network address. The address has stopped being evidence. Everything around it has to do the work instead.

How residential proxy detection actually works

Since the IP is honest, detection reads the behavior, the device, and the connection around it, and looks for the places where a routed session cannot keep its story straight. Four kinds of signal carry the load.

Rotation and velocity. A real home connection does not jump from one city or ISP to another between requests in the same session. A rotating residential proxy does exactly that, so an address that moves faster than a person physically could, or that changes networks mid-session, is a strong tell. This is the same logic behind impossible travel, read at the level of a single session.

Connection density. One home gateway serves one household. When many unrelated accounts or a burst of automated actions all originate from the same residential address at the same time, the address is no longer behaving like a home, it is behaving like an exit node.

Device linkage. This is the one that matters most. The IPs scatter across a rotating pool, but the device behind them does not change. Reading the device rather than the address links the sessions the rotation was meant to separate, so a hundred fresh home IPs collapse back into the one machine driving them. When we tested traffic routed through rotating residential pools, this was the signal that held: the exit IP changed on nearly every request, but the device signature underneath stayed the same. The address rotates; the device does not.

Network contradictions. The transport layer often disagrees with the residential story. A TLS or JA4 fingerprint that matches a scripting library or a server stack, not a consumer browser, contradicts the home IP. Latency and round-trip timing can reveal the extra hop through an intermediary. And a WebRTC or DNS leak can expose the real datacenter address sitting behind the residential exit.

The principle tying these together is simple: a residential proxy can fake the address but not everything attached to it. The contradiction between the clean home IP and the device, behavior, and connection around it is the signal.

Residential vs datacenter proxy detection

The two are not the same job, because the address is informative in one case and useless in the other:

	Datacenter proxy	Residential proxy
Address type	Hosting or cloud range	Real consumer ISP home IP
IP reputation	Often already flagged	Clean, belongs to a real home
ASN / ownership	Cloud provider, easy to spot	Ordinary residential ISP
Blocklists	Reasonably effective	Stale almost immediately
What actually catches it	The address itself	The device, behavior, and connection around the address

Datacenter proxy detection can lean on the network layer. Residential proxy detection has to corroborate everything else, which is why it is the harder problem and why an IP lookup alone never settles it.

What residential proxy detection can and cannot do

Residential proxies are the hardest masked traffic to identify, and honest detection says so. No single signal is reliable: a clean home IP proves nothing, a rotation can be coincidence, a device match can be a shared family computer, and a busy home IP is not always one household, because carrier-grade NAT and large shared ranges can legitimately put many real users behind a single residential address. That is exactly why connection density has to raise the score rather than settle anything on its own. What works is corroboration, several weak-on-their-own signals pointing the same way, which is why good detection raises confidence toward, but never to, certainty. 99.9 percent is an honest ceiling; 100 percent is a sales claim.

It also helps to remember that residential proxies have legitimate uses, such as ad verification and price-comparison research, so their presence is a risk signal tied to what the session is trying to do, not proof of fraud on its own. A residential proxy on an idle page view is noise. The same proxy on a tenth signup from one device this week, with a datacenter TLS stack underneath, is a story worth acting on.

Detecting residential proxies with ShieldLabs

ShieldLabs uses device intelligence together with connection analysis and pre-built blocklists, and flags the connection with an anonymous-proxy signal. But because residential proxies can be used for legitimate reasons, that signal has to be weighed together with the other risk signals, such as anti-detect browser usage, OS mismatch, timezone mismatch, and others. This layered approach helps your team move from spotting anomalies to confident, well-grounded decisions.

The ShieldLabs analytics dashboard also surfaces the anomalies where many accounts trace back to one device or one account spreads across many devices, and assigns a risk score to each identified visitor. You get the risk score and named risk signals through the API and webhooks to make accurate, well-grounded decisions.

Sources

Stanford Secure Computer Systems Group: Residential Proxy Detection (RESIP research)
arXiv: Characterizing and Detecting Residential Proxies (2412.03023)
Wikipedia: Proxy server
Wikipedia: Autonomous system (Internet)
MDN Web Docs: WebRTC API
IETF: RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space (carrier-grade NAT)
Bitsight: Residential proxy services and malware ecosystems

FAQ

Can residential proxies be detected?

Yes, but not by the IP address alone. Because a residential proxy uses a real home IP with a clean reputation, reputation lists, ASN checks, and blocklists mostly miss it. Detection instead reads the signals around the address: rapid IP rotation across locations, many accounts behind one home gateway, the device that stays the same while the IPs change, and network contradictions like a datacenter-style TLS stack or a leaked real IP. Residential proxies are harder to detect than datacenter proxies or VPNs, but they are not undetectable.

What is the difference between a residential proxy and a datacenter proxy?

A datacenter proxy routes traffic through a hosting or cloud IP address, which is easy to recognize because the address belongs to a known provider and often already carries a poor reputation. A residential proxy routes through a real home IP assigned by a consumer ISP, so it looks like an ordinary visitor and defeats address-based checks. The practical result is that datacenter proxies are caught by the address itself, while residential proxies have to be caught by the device, behavior, and connection around the address.

Why do fraudsters use residential proxies?

Because a residential IP carries the trust of a real home connection. It lets one actor look like many separate, legitimate customers, sidesteps reputation and blocklist checks, places the traffic in a plausible location, and rotates to break rate limits and the one-IP-per-account assumption. That combination is why residential proxies show up behind multi-accounting, account takeover, and offer abuse.

Are residential proxies illegal?

The proxies themselves are not illegal, and they have legitimate uses such as ad verification and market research. What can be illegal is the activity routed through them, such as fraud or unauthorized access, and the way some networks source their IPs, by enrolling people's devices without clear consent, raises its own problems. For a detection layer, a residential proxy is a risk signal tied to what the session is doing, not an offense in itself.

Does ShieldLabs detect residential proxies?

ShieldLabs reads the device and connection behind a session rather than trusting the IP, so it links rotating residential IPs back to one device and weighs network contradictions like a mismatched TLS stack against the clean home address. Those signals feed a risk score from 0 to 100 with the reasons named. ShieldLabs scores the session and hands the result, through its API and webhooks, to the rules you build on top, and the free tier covers your first 5,000 identifications.

Originally published on the ShieldLabs blog.