Published: August 13, 2026
The Email Verification origin trial started in Chrome 150. Based on your feedback, we've made several fixes and improvements. This post provides an overview of the changes and the actions you should take on your site or service.
First, a recap on the email verification functionality (or refer to the earlier announcement for more detail). A common pattern on sites has the user entering an email address as part of sign-up, sign-in, account recovery, and others, and then having to go to their email to click a magic link or obtain an OTP. Email Verification offers a progressive enhancement over this by verifying the email address with the provider directly in the browser. The site then receives a token from the browser that it can validate with the email provider and skip sending that email altogether.
User-facing updates
Changes in the user interface or user-facing behavior.
Email entry
Previously, users had to use autocomplete or autofill to enter an email address. Now, entering an email address in the field in any way (for example, typing or pasting.) triggers the verification process once the user exits the input element, similar to a change event. This means the email verification should effectively trigger for any email address entry.
Progress indicator
We are also testing a progress indicator for the verification process in Chrome 152+. While the verification process is quick, it's still possible for a user to submit the form before the process has completed. The progress indicator shows a spinner while verifying and then a checkmark on completion at the inline end (right side for a LTR language) of the input field.
If this causes any issues or you see any unexpected behaviour, then raise a bug.
Desktop only
Email Verification is only available on desktop up to Chrome 152. We are actively exploring support on Android too and will update here in the future.
Verifier updates
Changes for sites collecting and verifying emails.
Token validation
The email verification token is provided in the Selective Disclosure for JSON Web Tokens (SD-JWT) format. In its raw form this looks like this, an Issuer-signed JWT, followed by zero or more Disclosures, and ending with a Key Binding JWT with each component separated by a tilde:
<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>
The email verification token, in its current form, returns only the Issuer-signed JWT and the Key Binding JWT without any disclosures included. The original blog post and the first iteration of the demo were just splitting the token in two and parsing the two JWTs. This is fragile and would break if selective disclosures are added in the future.
Rather than relying on this feature of the current proposal, you should ensure that your implementation is correctly parsing the SD-JWT token as per its specification, ideally by using libraries for your platform. For example, the demo verification code now uses @sd-jwt/core to parse the token and validate the key binding (audience, nonce, and hash) and then jose to verify the signatures for the issuer's EVT and the browser's Key Binding JWT.
Third-party origin trials
Third-party origin trials are not supported for email verification as of August. Third-party origin trials allow a third-party origin to enable the trial functionality on a site where they're included, for example, a cross-origin JavaScript dependency. If this is a priority for your use case, comment or follow on the tracking bug.
Case-insensitive email comparison
A reminder that email providers may return the canonical email address with uppercase letters, for example, Demo.User@example.com even if demo.user@example.com was provided in the form. Ensure you're making a case-insensitive comparison with the received email address. We've also fixed a bug in the settings page where you may have seen case-sensitive variations of the same email address listed.
Provider updates
Changes for email providers.
HTTP Message Signature for issuance requests
We are introducing a breaking change in Chrome 153 where the issuance request will send only the email in application/json format with HTTP Message Signatures.
- Chrome 152 (and earlier): The issuance endpoint receives an
application/x-www-form-urlencodedPOSTrequest with therequest_tokenin the body. - Chrome 153 (and onwards): The content type changes to
application/jsonwith theSignature,Signature-Input, andSignature-Keyheaders, and a body containing theemailkey only.
Depending on your current traffic levels and goals in your testing, you can either:
- Support both formats and switch based on the content type. Once Chrome 153 reaches Stable at the end of August, you can evaluate your traffic to remove the legacy functionality.
- Just switch to the new format meaning verification will fail for users on earlier versions of Chrome.
The issuance endpoint in the demo code has been updated to handle both flows using structured-headers and http-message-sig.
Full request format:
POST /email-verification/issuance HTTP/1.1
Host: provider.example
Accept: application/json
Content-Digest: sha-256=:aBc123aBc123aBc123aBc123aBc123=:
Content-Type: application/json
Signature: sig=:+dEf567dEf567/dEf567dEf567dEf567/dEf567==:
Signature-Input: sig=("@method" "@authority" "@path" "content-digest" "signature-key");created=1786455840
Signature-Key: sig=hwk;crv="Ed25519";kty="OKP";x="gHi890_gHi890_gHi890"
{email: "demo@example.com"}
The response format stays the same: an issuance_token in an application/json body.
You can read and raise additional feedback on the proposal repos: WICG/email-verification and dickhardt/email-verification. The community response so far has been extremely helpful, so you can expect the updates and improvements to continue.