Email Verification Protocol Checker

Test your browser against the Email Verification Protocol, try a genuine EVP form, and see what is missing.

Your browser, checked live

The Email Verification Protocol (EVP) lets a browser prove you control an email address by fetching a signed token from your email provider. No verification email, no OTP, no magic link. It is an experimental Chrome origin trial, so most browsers cannot run it yet. This page checks what your browser can and cannot do, honestly.

CheckResultWhat it means

Try a real EVP form

This is a genuine verifier form built exactly the way the specification asks: an email field plus a hidden token field. On a browser where EVP is enabled (origin trial token or the browser flag) with a participating provider, the browser fills the token field by itself when you submit. Everywhere else the field stays empty, which is the designed fallback, and the page explains why. Your email is never sent anywhere by this demo.

Form nonce: (a fresh random value per form, as the spec requires)

Or check the provider side

EVP also needs the email domain to publish a discovery record. Enter a domain to see whether it does.

What is being checked, in thirty seconds

Email verification today means leaving the page: an inbox trip, a one-time code, a magic link that lands in spam. The Email Verification Protocol moves that proof into the browser. The site adds two form fields. When you submit, the browser asks your email provider, where you are already signed in, for a signed token that says you control the address, and hands the token to the site instead of an email.

The protocol is real but young: a WICG specification, an IETF internet-draft, a Chrome origin trial, and two issuers live today (Google for Gmail, and Hellō). Nothing here replaces your existing verification flow yet. These lab pages exist so developers can see the moving parts while the standard settles.

Frequently Asked Questions

An experimental web protocol, incubated at the WICG with an IETF internet-draft, that lets the browser prove a user controls an email address. The browser fetches a signed token (an SD-JWT) from the email provider, where the user already has a session, and gives it to the website. No verification email, OTP or magic link is involved.
Only Chromium browsers, and only experimentally. Google runs an origin trial in Chrome on desktop and Android, and Edge has run trials too. Firefox and Safari have no implementation. Sites cannot feature-detect support: the specification makes the token an optional form field, with the old email flow as the fallback.
Google issues tokens for Gmail addresses, and the identity cooperative Hellō runs a public issuer. A provider joins by publishing a DNS TXT record at _email-verification.<domain> naming its issuer, plus issuer metadata at /.well-known/email-verification. The domain checker in this lab looks both up.
That is the expected result almost everywhere today. The origin must be enrolled in the origin trial or the browser flag must be on, the email domain must publish an EVP record, and you must be signed in to that provider in the same browser. If any link is missing, the browser silently does nothing and the site falls back to a normal verification email.
No. It is a progressive enhancement under active development, and the issuer API still changes between Chrome versions. Production sites should add the form fields, accept a token when one arrives, and keep their existing verification email flow untouched for everyone else.

Was this tool helpful?

Comments

Loading comments...

Check Out Other Popular Tools