Google has opened a Chrome Origin Trial for the Email Verification API, a WICG proposal that lets the browser confirm a visitor owns the email address they entered without sending any mail. The trial starts with desktop Chrome 150, and Gmail is the first participating provider.
The proposal is meant to replace one-time codes and magic links. After someone enters an address, they often leave the page, open an inbox, copy a code, and return. That context switch is a common cause of drop-off.
It uses a three-party model. The browser sits between the website (the “verifier”) and the mailbox provider (the “issuer”). If the user 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 made the request.
For developers, the front end is relatively direct: the email field needs an autocomplete hint, and a hidden input carries a session-bound nonce. The heavier work is on the server, which checks the token signature with the provider’s key. Phil Nash of Resend has written a practical guide to the flow and released an npm package and a Next.js example for parsing and verifying tokens.
On Hacker News, one developer said jumping to an inbox during signup is “simply the worst context switch,” and that email verification had already led them to abandon registration “dozens of times, or possibly hundreds.” Another user said verification messages are often blocked or filtered to spam, and that people cannot tell whether mail is delayed or lost, so removing that step is an improvement.
One commenter called the privacy advantage tenuous: it complicates something that already works, and “there is no advantage.” The claimed benefit is that privacy is improved because the browser relays the request and the issuer does not know which web app asked. The commenter replied that sites already send welcome, onboarding, or reminder mail after verification, so user privacy is not enhanced. In that view, the result is a new flow that solves nothing while making everything more complicated, and over the long term that complexity helps large companies and hurts smaller ones. The same comment, marked as unproven, said it feels like a Google draft that would push the web toward being closed.
Another commenter said 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], noted that if the provider cannot attest to those aliases, the flow still has to fall back to the traditional method. Others compared it with FedCM and said 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 should watch for breaking changes. Chrome’s October update adds Android and a third-party Origin Trial in Chrome 154, renames the Sec-Fetch-Dest issuance value to email-verification, and, from Chrome 156, returns the email address 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 used as progressive enhancement, while the WICG continues to collect feedback from sites, providers, and users.
Source: InfoQ China. That article cites the English report at https://www.infoq.com/news/2026/10/chrome-email-verification/.