Chrome tests Private Verification Tokens: a one-bit signal telling sites an Incognito visitor is human

Google's Chrome team is running an origin trial of Private Verification Tokens (PVT) from Chrome 154 through Chrome 165, a mechanism that lets a website carry one bit of trust earned during normal browsing into an Incognito session on the same site, so a real person there can skip a CAPTCHA. The Chrome Platform Status entry was created on 2 April 2026 and last updated on 3 September 2026, and the design document states that the feature has not been approved to ship, according to PPC Land in a report published on 12 September 2026.

For marketers and site owners, this touches three everyday problems: CAPTCHA friction that costs form completions, bot and invalid traffic that pollutes reports, and private-browsing visitors who look like bots. It is also easy to overread. PVT is an experiment, it is limited to registered sites, and it carries almost no information by design. This article explains what it does, what it cannot do, and what a marketing or analytics team should do about it now, which is mostly to watch.

The problem Private Verification Tokens try to solve

A site cannot easily tell a person browsing in Incognito from a bot that has just wiped its own memory. Both arrive with no cookies and no stored history, so both tend to get the same CAPTCHA. The explainer's motivation section attributes the growth in site challenges to a significant increase in automation over the past one to two years, driven largely by AI, according to PPC Land.

The proposal's answer is to let a site give a browser a small cryptographic ticket while the person browses normally. When that person later opens the same site in a private window, the browser presents the ticket once. The ticket says one thing only, has no name attached to it, and works on at most two sites per private session.

How the mechanism works, in plain terms

PVT is defined in the documentation as a low-entropy mechanism that lets users transfer trust established during regular browsing into private browsing mode, to reduce the friction they face there. It is built on a cryptographic protocol called Anonymous Tokens with Hidden Metadata, abbreviated ATHM.

Two properties bound it. The first is direction. Tokens are issued in a regular session and redeemed in a private one, and the explainer says data can only go into private browsing and cannot be exfiltrated back out. The second is scope. Tokens are tied to the top-level origin's eTLD+1, which is the registrable domain, such as example.co.th. Issuance and redemption are restricted to origins sharing that domain, so a token earned on one publisher cannot be spent on another.

Registration comes first

Sites do not get access by default. Top-level websites must register to issue PVTs, and registration requires accepting a policy stating that tokens are used for trust, rate limiting and invalid traffic detection. According to the explainer, the process will resemble Private State Token registration. The registration process itself is marked as still to be determined. A site counts as registered if its eTLD+1 is registered, and the list of registered domains is to be pushed to browsers alongside public keys through mechanisms similar to Chrome's component updater.

The four conditions before Chrome asks for a token

Issuance does not happen on every page view. The browser builds a token challenge only when four conditions hold at once, according to the design document as reported by PPC Land.

1. The request goes to an https origin whose eTLD+1 appears on the registered list.
2. The request comes from a regular browsing session, defined as a context where keeping data after the page closes is appropriate.
3. The number of tokens already held for that eTLD+1 is below a threshold, which the document frames as keeping tokens fresh rather than letting a browser hoard them.
4. The tokens already held are close to expiry, so the browser tops up before it runs out rather than after.

The exchange itself uses ordinary web plumbing. A token challenge is a POST to a path the page specifies, with an Accept header of application/private-token-response and a Content-Type of application/private-token-request. A successful response returns HTTP 200 with the token response. The browser verifies the proof, stores the token in site data and writes it to disk so it survives restarts. The issuer selects the hidden metadata, which is the one bit, and the origin extracts it at redemption, returns a verdict and, if the verdict passes, skips the challenge.

Redemption: one token, one header, cookieless requests only

In a private window, the first request to a registered site has no cookie by definition, and that request carries the token. It travels in a new HTTP header named Sec-Private-Verification-Token, holding a base64 encoding of a single serialized token, with serialization following section 5.3 of RFC 9578.

Four conditions govern redemption as well: the request has no cookie, the scheme is https, the parent profile holds at least one token for that site, and the tokens have not expired. Only one PVT is sent to a registered origin during a single private browsing session.

Sites must set a cookie or burn their tokens

Because the browser attaches a token to any cookieless request to a registered site, a site that never sets a cookie would drain the supply. The explainer puts the fix on the site: an origin can stop burning its PVTs by setting a cookie once it receives one. Without that, the browser keeps attaching tokens until none are left. For a team planning to take part, this is an implementation detail worth writing down early.

The limits are the specification

The table below summarises the hard limits described in the design document, as reported by PPC Land.

The two-site cap is deterministic. Only the first two registered domains a private session encounters get a token. The explainer compares this to Firefox's bounce tracking mitigation, notes that its own rule is deterministic rather than heuristic, and presents it as a defence against one company running several registered domains to gather more signal than intended.

Unlinkability comes from ATHM. Tokens with the same hidden metadata are indistinguishable, so a site receiving a redemption cannot tie the visitor back to the moment the token was issued on the strength of the token alone.

Expiry is bounded on both sides. Tokens expire when their keys expire, and browsers are told to reject keys whose expiry is too near, because short-lived keys would let sites sort users by which key version they hold. User control is written in: existing data persistence rules apply, sites blocked from storing data cannot store tokens, and browsers are expected to offer controls to clear stored tokens and to switch the mechanism off.

Hiding private mode from sites: prefetch and a proxy

The design creates a detection risk that the document states openly. If tokens existed only in private mode, their presence would itself reveal that a session is private. The proposed mitigation is to prefetch tokens at browser startup, so a supply exists in both modes and on a person's first visit to a site.

That creates a second problem. If every Chrome installation prefetched tokens directly, a website could in theory count the whole browser fleet. The counter-measure routes prefetch requests through a PVT proxy server run by the browser vendor. The proxy identifies itself, PVT endpoints must respond to its token requests, and the browser is expected to schedule requests so it does not overload the proxy or the site's endpoint. PPC Land describes the result as a three-party arrangement: Chrome sees the request volume, and the site sees the redemption.

How PVT relates to Private State Tokens and PACT

The source does not describe PVT as a replacement for the Private State Tokens API. The explainer says PVT registration will resemble Private State Token registration. PPC Land notes that Private State Tokens are the anti-fraud mechanism Google kept when it retired most of the Privacy Sandbox in October 2025. That is the extent of the relationship the source describes: a shared model for registration, within the same anti-fraud family.

The explainer also positions PVT as a partial answer to a broader proposal called PACT, incubated in the Anti-Fraud Community Group, and includes a requirement-by-requirement table rather than claiming equivalence.

• Answered yes: frictionless challenges, unlinkability, minimal information leakage, computational efficiency (relative to proof of work) and collusion resistance (credited to the two-domain cap). The leakage answer carries a note that PACT has not yet defined entropy limits.
• Answered no: blocking and feedback.
• Answered partially: openness to participation, limited by the registration policy and an expected lower issuer adoption; and effective rate limiting, which publishers control only indirectly through token supply.
• Not applicable: minimal coordination, because publisher, issuer and redeemer are the same entity.

The architectural difference matters most for anyone thinking about advertising. PACT contemplates a low-entropy signal available both at top level and in third-party contexts. PVT is available on a single top level only, and it crosses into private browsing in one direction, with low-entropy data in and no data out.

Where the work sits: an origin trial, not a launch

Chrome Platform Status lists origin trial milestones of 154 to 165 for desktop and the same range for Android. The iOS and WebView rows are empty. Firefox, WebKit and web developers are all recorded as giving no signal, and the TAG specification review is pending. Five Google addresses are listed as owners.

The rollout plan field says the feature will ship enabled for all users. PPC Land reads that line as intent at the end of a process, not the current state. The design document says plainly that the work has not been approved to ship.

The stated experiment goals are narrow. The trial aims to check whether positive reputation a user builds on a site in regular browsing can earn a lower-friction experience on the same site in private browsing. Participants are expected to iterate on how they issue tokens during the experiment, and the correlation between the carried reputation and existing signals of benign use is to be validated. The overall aim is friction reduction, but the goal for the experiment itself is to validate whether the signal helps bot detection defences.

According to the Intent to Experiment post on the blink-dev mailing list, the feature sits behind a flag named kEnablePrivateVerificationTokens, has no WebView support and is not covered by web-platform-tests. The public explainer repository had 24 commits, nine stars, two forks and five contributors when PPC Land captured it.

An outside reading

Stan Sadokov, chief executive of proxy vendor NodeMaven, posted an assessment on LinkedIn on 11 September 2026, writing: "If it ships to production, it will change how scraping works." He also said Chrome 154 reached beta on 2 September 2026, a date that does not appear on the Chrome Platform Status entry. PPC Land notes his vantage point is commercial, and that he acknowledged the proposal is an early sketch limited to Incognito and Chrome that changes nothing in production.

What PVT does not do

Much of the confusion around browser trust signals comes from reading them as identity or targeting tools. PVT is neither, and the design says so in several places.

• No identity. The token carries one bit. There is no user ID, no score and no browsing history in it.
• No cross-site use. A token issued on one registrable domain can only be redeemed on that same domain.
• No third-party context. PVT works at top level only, unlike the broader PACT idea.
• No data out of private mode. Information goes into the private session and nothing travels back.
• No blocking or feedback. The explainer's own PACT table answers no to both.

PPC Land's conclusion is that anyone reading a browser-level trust primitive as a cookie replacement will find the document unhelpful on that point, deliberately so. It also notes that the registration policy explicitly names invalid traffic detection as a permitted use, which places a browser-native signal in the same problem space as traffic verification tools, although the token appears only on a cookieless first request in a private session.

What marketing and analytics teams should do now

For most teams, there is nothing to deploy. PVT is an origin trial, sites must register, the registration process is still to be determined, and the feature has not been approved to ship. Practical steps are about understanding and preparation.

1. Do not change bot filtering or CAPTCHA setups because of PVT. Tokens are issued only by registered sites, the registration process is still to be determined, and a trial can end without shipping.
2. Do not expect a new analytics dimension. The source describes no reporting, no identifier and no data flowing to measurement tools. Private browsing visitors will still arrive without cookies.
3. Know where friction hurts. If a site challenges visitors on lead forms, login or checkout, it is worth knowing how much of that traffic arrives cookieless, so the team can judge later whether a one-bit signal would matter.
4. Ask developers to watch the trial. The things to follow are the registration process, any change in the Chrome Platform Status entry, signals from Firefox and WebKit, and the TAG review.
5. Note the cookie rule if you take part. A registered site that does not set a cookie after receiving a token would burn through its supply.

What the source did not say

PPC Land does not say how registration will work, who will be allowed to register, or when it will open. It does not report any participating sites, results from the trial or effects on CAPTCHA completion rates. It gives no timeline for shipping beyond the trial window through Chrome 165, and it does not say whether Chrome on iOS or WebView will ever be included. It also does not describe any link between PVT and Google Analytics, Google Ads invalid click filtering or any other advertising product.

What this means for Thai marketers

The source does not mention Thailand, and the trial covers Chrome on desktop and Android globally, with no market-specific rules described. For Thai brands whose lead forms and checkouts depend on CAPTCHA protection, the proposal is worth tracking because it targets the exact visitors who suffer most from challenges: people using private windows. For teams reporting on traffic quality in GA4 analytics setups or managing invalid traffic concerns around Google Ads campaigns, the honest position today is that PVT changes nothing in the data. It could matter later if it ships and registration opens, and the two-site cap and one-bit payload mean it will never become a targeting or attribution signal as designed.

FAQ

What are Chrome Private Verification Tokens?

They are a proposed Chrome mechanism that carries one bit of trust from normal browsing into a private browsing session on the same site. A registered site issues a token during regular browsing, and Chrome presents it once in Incognito so the site can skip a challenge such as a CAPTCHA.

Is Private Verification Tokens live in Chrome?

No, it is in an origin trial from Chrome 154 to Chrome 165 and has not been approved to ship. The design document says so directly, and the TAG review is still pending.

Can Private Verification Tokens identify or track users across sites?

No, according to the design. The token holds a single bit, can only be redeemed on the registrable domain that issued it, works on at most two registered domains per private session, and no data travels out of the private session.

Can any website use Private Verification Tokens?

No, only registered sites can issue them. Registration requires accepting a policy limiting use to trust, rate limiting and invalid traffic detection, and the registration process itself is still to be determined.

Should we change our analytics or bot filtering now?

No, there is nothing to change yet. The trial produces no new analytics data described by the source, so the useful step is to monitor the Chrome Platform Status entry and registration news.

Private Verification Tokens are a small, tightly fenced experiment aimed at one of the web's more irritating problems. If your team wants help understanding how bot traffic, CAPTCHA friction and private browsing affect your own analytics before any of this ships, Relevant Audience can walk through the data with you.