Test the Email Verification Protocol with an origin trial | Blog | Chrome for Developers

Skip to main content

English

Deutsch

Español – América Latina

Français

Indonesia

Italiano

Nederlands

Polski

Português – Brasil

Tiếng Việt

Türkçe

Русский

עברית

العربيّة

فارسی

हिंदी

বাংলা

ภาษาไทย

中文 – 简体

中文 – 繁體

日本語

한국어

Sign in

Blog

Chrome for Developers

Blog

Test the Email Verification Protocol with an origin trial

Stay organized with collections

Save and categorize content based on your preferences.

Rowan Merewood

GitHub

Mastodon

Bluesky

Published: July 8, 2026

When collecting an email address as a part of a sign-up, sign-in, subscribe,<br>checkout, account recovery, or other process, it's common practice to confirm<br>that the email address is owned by the person entering it. Existing verification<br>methods, like one-time passwords (OTPs) or email verification links (magic<br>links), require the user to navigate away from your site. This disruptive<br>process can increase the risk of the user, whether a human or an agent,<br>abandoning their session entirely and never completing their authentication<br>process.

The Email Verification API is a proposal that allows the browser to communicate<br>directly with the email provider to verify that the user owns the email address.<br>Users select an email from the browser's autofill or autocomplete suggestion,<br>submit the form, and the site verifies the email address with the provider<br>without sending an email or interrupting the user's flow.

Email Verification API user prompt demo

Email collection is a critical conversion point in a user's journey, and Chrome<br>would like feedback on the proposal from sites<br>that want to verify emails, email providers that can perform the verification,<br>and users experiencing the process. You can<br>sign up for the origin trial<br>today and follow the implementation instructions here. For general origin trial<br>configuration, refer to Getting started with origin<br>trials.

You can try the flow with a demo account:

Issuer demo gives you a mock email<br>account and session

Verifier demo will verify any<br>participating provider

Note: Gmail is participating in the origin trial as a provider. You can test the<br>verification flow with any @gmail.com address without additional<br>configuration.<br>Email verification flow

The following sections explain what you and your users need to start the email<br>verification flow, and the whole workflow when using the Email Verification<br>Protocol.

Key terms

Key terms for the Email Verification API are as follows:

Verifier : The site that collects the email address and wants to verify<br>it. The verifier is also called the Relying<br>Party.

Email Provider : The service providing the user's email address, for<br>example gmail.com.

Issuer : The service that manages the account for the user's email, for<br>example accounts.google.com. The issuer is also called the Identity<br>Provider.

In some cases, the email provider and the issuer may operate from the same<br>domain. However, it's important to distinguish between having an email address<br>and having an active session for the associated account.

Email Verification flow architecture

Prerequisites

The user must be signed in to their email provider or issuer on the same<br>browser profile. For example, if they use Gmail, they must be signed into<br>their Google Account.

As a participating verifier site, you must sign up for the origin trial<br>and provide the token on the same page as your email form.

The user must select their email address from the autofill or autocomplete<br>drop-down.

If the user has previously entered an email address in the field, it<br>will be offered using autocomplete.

If the user has added their email address using Chrome settings<br>"Autofill and password" (chrome://settings/autofill) it will be<br>offered using autofill.

Note: Support for manually typed addresses is planned for a future release.

The first time a user provides an email address for verification they will<br>see a permission prompt. This only occurs once per email address.

Once the user has that active session in their browser, they can start the<br>process:

On a form with an email field, the user selects their email address from the<br>autocomplete drop-down. The verifier site provides a hidden field in the<br>form with a per-instance nonce to validate this request.

The browser will then retrieve the email verification DNS record for the<br>email domain. This points the browser to the issuer. The issuer will then<br>confirm that they have an active session for that email address.

Note: These requests don't reveal any additional information about the<br>user. The verifier site does not receive information during this step.<br>The issuer only sees a request to verify the user exists; it does not<br>see which site initiated the request.

The issuer will then provide their Email Verification Token (EVT) for the<br>address. The browser combines that into a key bound JWT with the EVT, the<br>site origin, and the nonce from the input form.

When...