How PerimeterX (HUMAN) Works (2026)

PerimeterX is a reverse-proxy WAF: it sits between visitors and the real site, so every request passes through it first. At its edge it builds a per-request trust score from four inputs — the visitor's IP reputation, sensor data gathered in the browser, TLS handshake details (TLS is the encryption layer behind https), and behavioural telemetry (signals about how the visitor acts).

If a request scores low on trust, the visitor sees one of these:

• A silent 403 or 429 error with x-px-block headers.
• A press and hold human-verification challenge that measures touch pressure, mouse velocity, hold duration and tiny involuntary movements.
• A full block page with a ref ID.

The scorer is intent-blind: it doesn't care what you're trying to do. Any client that doesn't look like a real browser gets the same low score whatever its purpose.

1. IP address reputation

• Datacenter IPs (AWS, GCP, Azure, DigitalOcean, OVH…) — pre-scored low, because real people rarely browse from servers. Many cloud IP ranges are blanket-blocked on protected sites before any fingerprint check even runs.
• Residential IPs — the addresses ISPs hand out to home connections, treated as much higher trust.
• Mobile IPs — cell tower and CGNAT pools (where a carrier shares one IP among many phones), given the highest baseline trust because these pools rotate naturally.

IP reputation dominates the very first request's score, before the sensor has reported anything.

2. JavaScript sensor and the _px* cookie chain

This is the layer PerimeterX is best known for. Every protected page loads a heavily-obfuscated sensor script (JavaScript deliberately scrambled so it's hard to read or tamper with). It runs in the browser and collects hundreds of data points: canvas/WebGL fingerprints (how your graphics hardware draws an image), audio context, installed fonts, screen metrics, timezone, language, plugin list, navigator.webdriver (a flag automation tools often leave on), the shape of window.chrome, the entropy of your mouse movements (entropy here means how random and human-like they look), and more.

The sensor sends an encrypted payload back to PerimeterX's collector, and the reply sets the cookie chain:

• _pxhd — long-lived device hash.
• _pxvid — visitor ID.
• _px3 — short-lived session token.

If that payload is missing or stale, PerimeterX fires the press and hold challenge — which itself records timing and pressure data that a scripted click can't easily produce.

3. HTTP and TLS fingerprinting

Before any HTML is exchanged, PerimeterX fingerprints the client from the TLS handshake (the opening exchange that sets up the https encryption — its exact shape is summarised as a JA3/JA4 signature) and from HTTP/2 behaviour.

• Most scraping libraries still default to HTTP/1.1. Real Chrome and Firefox haven't for years, so that alone stands out.
• libcurl and Go's net/http produce JA3 signatures that don't match any real browser, even when they do negotiate HTTP/2.
• HTTP/2 fingerprinting tracks the order of pseudo-headers, SETTINGS frame values, and window-update sizes — low-level details a real browser sets in a consistent way.

4. Behavioural and pattern analysis

PerimeterX also runs continuous machine-learning analysis on your connection history, looking for tell-tale patterns:

• Headers a real browser always sends that are missing (Sec-Fetch-*, Accept-Language, sec-ch-ua).
• The _px* cookies missing, or sent from a different IP than the one that originally created them.
• Hits on honeypot links (links hidden from humans but visible to bots).
• Bursty timing — requests fired faster or more regularly than a person would.
• Identical sensor payloads reused across pages instead of fresh ones.

The four signals are judged together, so fixing one alone rarely moves the score much. These are the broad categories of tooling that show up in real-world workflows:

• HTTP clients with browser-impersonating TLS — curl_cffi, curl-impersonate, tls-client. They copy a real browser's handshake, but they can't run the sensor script.
• Stealth-patched browsers — patchright, Camoufox, and Playwright with stealth plugins, which run the sensor inside a genuine browser context.
• Managed scraping APIs — services that bundle proxies, patched browsers and session persistence behind a single endpoint.

Reusing a session matters a lot on PerimeterX: the _px* cookies and the built-up behavioural state are far harder to recreate from scratch on every request than to keep warm across one ongoing session.

Real-estate, marketplaces, ticketing and sneaker resale dominate the list of protected sites. Many of these sites rotate between PerimeterX, Cloudflare, Akamai and DataDome depending on traffic conditions, so the same site can serve different defences at different times.

PerimeterX builds a continuous trust score from four things: IP reputation, the _px* JavaScript sensor and its cookie chain, TLS/HTTP/2 fingerprints, and behavioural patterns watched over time. The press and hold challenge is the most visible way to fail, but it's downstream of the sensor — by the time it appears, your score has already dropped. And like any modern WAF, its detection logic keeps changing on a rolling basis.