Google's Chrome team has put Private Verification Tokens into an origin trial spanning Chrome 154 through Chrome 165, a mechanism that carries a single bit of accumulated reputation out of normal browsing and into a private session that stores nothing. The Chrome Platform Status entry for the feature was created on April 2, 2026 and last updated on September 3, 2026. The published design document states plainly that the work has not been approved to ship.

In Short

Websites cannot tell the difference between a person browsing in Incognito and a bot that has just wiped its own memory, so both get hit with a CAPTCHA. Google is testing a way for a site to hand your browser a tiny cryptographic ticket while you browse normally, which your browser then presents once when you visit that same site in Incognito. The ticket says one thing only, carries no name attached to it, and works on a maximum of two sites per private session.

What the proposal describes

Private Verification Tokens, abbreviated PVT in the documentation, are defined as a low-entropy mechanism allowing users to transfer trust established during regular browsing into private browsing mode in order to reduce the friction they experience there. The design rests on the Anonymous Tokens with Hidden Metadata protocol, referred to throughout as ATHM.

Two properties bound the mechanism. The first is directional. Tokens are issued during a regular browsing session and redeemed during a private one, and the explainer states that 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, meaning issuance and redemption are restricted to origins sharing the same registrable domain. A token earned on one publisher cannot be spent on another.

Sites do not get access by default. Top-level websites must register to issue PVTs, and registration requires accepting a policy stating that the tokens are used for trust, rate limiting and invalid traffic detection. According to the explainer, the process will resemble Private State Token registration, the anti-fraud mechanism Google kept when it retired most of the Privacy Sandbox in October 2025. The registration process itself is marked as still to be determined. A site is treated 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.

Four conditions before a token is requested

Issuance does not fire on every page view. The browser constructs a token challenge only when four conditions hold at once, according to the design document.

The request must be headed to an origin using the https scheme whose eTLD+1 appears in the registered list. The request must originate in a regular browsing session, which the explainer defines as a context where persisting data after the page closes is appropriate. The count of existing tokens held for that eTLD+1 must sit below a threshold, a rule the document frames as ensuring token freshness rather than hoarding. And the tokens already held must be close to expiry, so that the browser tops up before running dry rather than after.

The wire format is deliberately conventional. A token challenge is a POST to a path the page itself specifies, carrying an Accept header of application/private-token-response and a Content-Type of application/private-token-request, with the serialized TokenRequest as the body. A successful response returns HTTP 200 with a Content-Type of application/private-token-response and the TokenResponse bytes. The browser verifies the response proof, stores the token in site data, and writes tokens to disk so they survive restarts. Hidden metadata is selected by the issuer at step five of the published flow diagram and extracted by the origin at step ten, after which the origin returns a verdict and, if the verdict passes, skips the challenge.

Redemption happens once, in a header

On the private browsing side, the first request to a registered origin carries no cookie by definition, and that is the request that carries the token. It travels in a new HTTP header named Sec-Private-Verification-Token, which holds a base64 encoding of a single serialized token. Serialization follows section 5.3 of RFC 9578.

Four conditions again govern the behaviour: the request carries no cookie, the origin's scheme is https, the parent profile holds at least one token for that origin, and the tokens have not expired. Only one PVT is sent to a registered origin during a single private browsing session.

There is a supply problem built into that design, and the explainer addresses it directly. Because the browser attaches a token to any cookieless request, a site that never sets a cookie would drain the cache. The stated remedy places the obligation on the site: an origin can prevent burning all of its PVTs by setting a cookie once it receives one. Absent that, the browser keeps attaching tokens until none are left.

A proxy server to hide the fleet

The mechanism creates a detection risk that the document does not bury. If tokens were present only in private mode, their presence would itself expose that a session is private. The proposed mitigation is to prefetch tokens at browser startup so that a supply exists in both modes and on a user's first visit to a site.

That mitigation creates a second problem. A prefetch performed by every installation could, in theory, let a website enumerate the entire browser fleet. The counter-mitigation routes prefetch requests through a PVT proxy server operated by the browser vendor. The proxy identifies itself as such, PVT endpoints are required to respond to its token requests, and the browser is expected to schedule those requests so as not to overload either the proxy or the origin endpoint. The result is a three-party arrangement in which the party that sees the request volume is Chrome, and the party that sees the redemption is the site.

Chrome has built comparable intermediary plumbing before. Its IP Protection work for Incognito mode used a two-hop proxy so that no single operator held both a user's address and their destination, an approach that was itself later folded into the Privacy Sandbox retrenchment.

The limits are the specification

Most of what makes this proposal distinct sits in its ceilings rather than its capabilities.

Token capacity is a single bit. The document proposes nBuckets equal to two, which is the whole payload. There is no score, no tier and no history in the token.

Distinct sites per session are capped at two. Browsers are to limit the number of distinct eTLD+1 values observed for redemptions in any given private mode session, and the proposed limit is two, so only the first two registered domains encountered receive a token. The explainer compares the rule to Firefox's bounce tracking mitigation while noting that this version is deterministic rather than heuristic, and frames it as a defence against a single entity operating several registered domains to accumulate more signal than intended.

Unlinkability follows from ATHM itself. Tokens carrying the same hidden metadata are indistinguishable, so an origin receiving a redemption cannot tie the user back to the issuance context on the strength of the token.

Key and token expiry are bounded on both sides. Tokens expire when their keys expire, and browsers are instructed to reject keys whose expiry is too near, on the grounds that short-lived keys would let sites classify users by which key version they hold. Keys reach browsers through a component-updater-style channel.

User control is specified rather than assumed. Existing data persistence rules apply, origins blocked from persisting data must not be able to store tokens, and browsers are expected to implement interface elements both to clear stored tokens and to disable the mechanism entirely.

Where the work sits in the process

Chrome Platform Status lists desktop origin trial milestones of 154 to 165 and identical Android milestones of 154 to 165. The iOS and WebView rows are empty. Firefox, WebKit and web developers are all recorded as having given no signal. The TAG specification review status reads pending. Five Google addresses are listed as owners, the Blink component is recorded as Blink, and the web feature identifier is marked missing. The rollout plan field states that the feature will ship enabled for all users, a line that describes intent at the end of a process rather than current state.

The experiment goals section is more specific than the marketing-facing summary. It states that the trial aims to verify whether positive reputation built by a user on a particular website in regular browsing can earn a lower friction experience on that same website in private browsing, that participants are expected to iterate on their token issuance methodology over the course of the experiment, and that the correlation between reputation carried across and existing signals of benign usage is to be validated. The ultimate goal is framed as friction reduction, but the stated goal for the experiment itself is narrower: to validate the usefulness of the signal in aiding bot detection defences. Experiment risks and ongoing constraints are both recorded as absent.

The public repository is modest by the standards of a shipping web platform feature. The explainers-by-googlers project carries 24 commits across six branches and no tags, nine stars, two forks and five contributors, under a CC-BY-4.0 licence, with the specification source written in Bikeshed. The most recent commit at the time the page was captured was a dependency update merged three weeks earlier. According to the Intent to Experiment posting on the blink-dev mailing list linked from the status entry, the feature sits behind a flag named kEnablePrivateVerificationTokens, carries a Finch feature name of the same string, has no WebView support and is not covered by web-platform-tests.

Measured against PACT

The explainer 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 a claim of equivalence.

On frictionless challenges, unlinkability, minimal information leakage, computational efficiency and collusion resistance, the table answers yes. Computational efficiency is qualified as an advantage relative to proof of work. Collusion resistance is credited to the two-domain cap. Minimal information leakage carries a note that entropy limits have not yet been defined in PACT, which makes the comparison partly unresolved.

Two requirements are answered no outright: blocking and feedback. Two are answered partially. Openness to participation is qualified by the registration policy publishers must accept and by an expectation that issuer adoption will be lower than PACT's, given the narrow use case. Effective rate limiting is qualified as something publishers control indirectly, by controlling token supply. Minimal coordination is marked not applicable, because publisher, issuer and redeemer are a single entity.

The document also names the architectural difference that matters most for anyone reading this as an advertising signal. 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 crosses into the private browsing context in one direction, with low-entropy data in and no data out.

The traffic problem behind the design

The motivation section attributes the change in site behaviour to a significant increase in automation over the past one to two years, driven largely by AI. That framing matches what has been measured elsewhere. Automated requests passed half of all web traffic in agency-side observations reported earlier this month, and a separate analysis found the United States originating 53.5% of global bot traffic.

The cost lands unevenly. A philanthropy database in Austin documented bots at more than 99% of its requests and blocked Amazon's crawler after 117,000 daily page reads, recording a CAPTCHA solve rate of 0.24% in the process. Industry bodies have started codifying responses: IAB Australia sorted crawlers into four verdict categories in July. Verification has been migrating toward cryptography on the bot side as well, through Cloudflare's registry format for bot and agent authentication and Google's own experimental web-bot-auth identity attached to Google-Agent. Identity claims made without cryptography have proved unreliable: scanners have been observed impersonating ClaudeBot from 824 addresses.

PVT approaches the same problem from the opposite end. Rather than authenticating the machine, it attests to the human, and it does so on the one surface where the human currently looks most like a machine.

A reading from the proxy side

Stan Sadokov, chief executive of the proxy vendor NodeMaven, posted an assessment of the trial on LinkedIn on September 11, 2026, writing of the mechanism: "If it ships to production, it will change how scraping works." His summary of the design matches the published documents on registration, disk storage, the header name, the one-token rule and the two-domain cap, and he characterises the single bit as the entirety of the reputation Google proposes a real user should carry into a session that remembers nothing. He also states that Chrome 154 reached beta on September 2, 2026, a date that does not appear on the Chrome Platform Status entry, which records only milestone numbers.

Sadokov's vantage point is commercial. Scraping infrastructure at scale runs on residential proxy networks that route requests through consumer connections, and a browser-issued humanness signal that cannot be minted by a headless client is a competitive variable for that market. His own framing acknowledges the limits, noting that the proposal is an early sketch confined to Incognito and to Chrome, and that it changes nothing in production.

Why this matters for the marketing community

The commercial reading has three parts, and none of them is a targeting story.

First, the registration policy explicitly names invalid traffic detection as a permitted use. That places a browser-native signal inside the same problem space occupied by verification vendors, whose pre-bid systems have been repeatedly shown to lack the credentials needed to separate bots from browsers. A token that only ever appears on a cookieless first request in a private session is narrow, but it is a signal the site itself holds rather than one purchased downstream.

Second, private browsing traffic has historically been treated as a measurement hole rather than a measurement category. Incognito sessions already produce litigation exposure, as the class action over Chrome's private mode data collection demonstrated when the Ninth Circuit closed off a late damages bid in April 2026. A mechanism that reduces challenge rates in that mode changes the composition of traffic publishers see there, and therefore the quality of the sessions monetised against it.

Third, the design forecloses the obvious extension. There is no cross-site identifier, no third-party context, no persistent score and no path for data to travel out of the private session. Anyone reading a browser-level trust primitive as a cookie replacement will find the document unhelpful on that point, deliberately so. The comparison table's two flat refusals, on blocking and on feedback, are the clearest statement of scope in the entire proposal.

What remains unresolved is the registration process itself, which the explainer leaves to be determined, and which will decide who can issue these tokens at all. Chrome has run trials before that ended in retirement rather than shipping, and the WebMCP origin trial opened in Chrome 149 is a reminder of how much browser-side agent infrastructure is being tested simultaneously. With no signal from Firefox or WebKit, a pending TAG review and a design document that disclaims approval to ship, the trial window through Chrome 165 is the only firm date on the record.

Timeline

Summary

Who: The Chrome PVT team at Google, with five engineers listed as owners on the Chrome Platform Status entry. Registered website operators act as issuers, verifiers and redeemers of the tokens. Stan Sadokov, chief executive of proxy vendor NodeMaven, published an outside assessment.

What: Private Verification Tokens, a low-entropy mechanism built on the Anonymous Tokens with Hidden Metadata protocol that carries a single bit of trust from regular browsing into private browsing on the same eTLD+1. Tokens travel in a Sec-Private-Verification-Token header on cookieless requests, one per origin per private session, with a cap of two distinct registered domains per session. Registration requires accepting a policy limiting use to trust, rate limiting and invalid traffic detection.

When: The Chrome Platform Status entry was created on April 2, 2026 and last updated on September 3, 2026. The origin trial runs from Chrome 154 to Chrome 165 on both desktop and Android. Chrome 154 reached beta on September 2, 2026 according to Sadokov's post.

Where: Chrome on desktop and Android, with iOS and WebView milestones unrecorded. The specification lives in the explainers-by-googlers repository on GitHub under a CC-BY-4.0 licence. Firefox and WebKit have given no signal, and the TAG specification review is pending.

Why: Websites have added challenges in response to a sharp rise in automated traffic, and private browsing users resemble automated clients because both present cleared local state. The proposal attempts to separate the two groups using the smallest signal its authors believe will work, without creating a cross-site identifier or allowing any data to leave the private session.