Google has opened a Chrome Origin Trial for the Email Verification API, a WICG proposal that lets the browser confirm a visitor controls the email address they entered without sending any mail. The trial starts with desktop Chrome 150, and Gmail is the first participating provider.
The idea is to replace one-time codes and magic links. After typing an address, people often leave the page, open an inbox, copy a code, and return. That context switch is a common source of drop-off.
The proposal uses a three-party model, with the browser between the site (the “verifier”) and the email provider (the “issuer”). If the person is already signed in to the email service, the browser fetches a signed token in the background and fills it into the form. The server checks the token when the form is submitted. Google says the issuer does not learn which site started the request.
For developers, the front end is described as straightforward. The email field needs an autocomplete hint, plus a hidden input carrying a session-bound nonce. The sample markup given is:
<input id="email"><input nonce={nonce}>
The heavier work is on the server, which must check the token signature with the provider’s key. Phil Nash of Resend has written a practical guide to the flow and published an npm package and a Next.js example for parsing and verifying tokens.
On Hacker News, one developer said jumping to the inbox during signup is “the worst context switch,” and that email verification had already led them to abandon signups “dozens of times, maybe hundreds.” Another noted that verification messages are often blocked or filtered to spam, and that users cannot tell whether a message is merely delayed or lost, so removing that step would be an improvement.
One commenter called the claimed privacy benefit tenuous: it complicates something that already works and brings “no advantage.” Responding to the claim that privacy is improved because the browser mediates the request and the issuer does not know which web app asked, the commenter noted that sites still send welcome, onboarding, or reminder mail after verification, so privacy is not actually enhanced. In that view, the result is a new flow that solves no problem while making everything more complex, and over time that complexity helps large companies and hurts smaller ones. The same commenter said this is unproven, but that it feels like a Google draft that would make the web more closed.
Another commenter argued that the issuer’s inability to see which site made the request is not a feature but a “functional defect.” Developers who rely on a different address for each recipient, such as [email protected], pointed out that if the provider cannot attest to those aliases, the flow still has to fall back to the traditional method. Others compared it to FedCM, saying it is consolidating identity capabilities into the browser the way password managers once did.
If the user is not signed in to Gmail in Chrome, the site falls back to a conventional confirmation email. Existing syntax, MX, and SMTP checks can still cover addresses the API cannot handle.
Teams already testing it should watch for breaking changes. Chrome’s October update adds Android support and a third-party Origin Trial in Chrome 154, renames the issuer value of Sec-Fetch-Dest to email-verification, and, starting with Chrome 156, returns the email address exactly as the user submitted it. Verifier and issuer guides continue to track the current protocol.
The Email Verification API remains an experimental proposal. For now it is best treated as progressive enhancement, while WICG continues to collect feedback from sites, providers, and users.
Source: InfoQ China, which cites the English report at https://www.infoq.com/news/2026/10/chrome-email-verification/.