Google Chrome | Email Verification Updates Improve Account Flows
Chrome is refining its experimental Email Verification flow with changes aimed at making account forms easier to complete without forcing users to leave a website. Published on August 13, 2026, the update expands how verification can start, adds clearer progress feedback, strengthens token-handling guidance, and prepares email providers for a breaking protocol change arriving with Chrome 153.
Chrome makes browser-based email verification easier to trigger
Email Verification is being tested as a progressive enhancement for common website flows such as sign-up, sign-in, account recovery, subscriptions, and checkout. Instead of sending a magic link or one-time password, the browser can verify ownership of the email address directly with a participating provider and pass a verification token back to the website.
The latest update removes an important interaction limitation. Users previously needed to enter their address through autocomplete or autofill to trigger verification. Chrome now starts the process after the user leaves the email input regardless of whether the address was typed, pasted, autofilled, or selected from autocomplete.
A progress indicator gives forms clearer verification feedback
Chrome 152 and later are also testing an inline progress indicator for the verification process. While verification is normally fast, users can still attempt to submit a form before the browser has finished communicating with the email provider.
The new interface places a spinner at the inline end of the email field while verification is running and replaces it with a checkmark when the process finishes. For web designers, this is a useful UX detail because the verification state becomes visible without requiring the website to build its own progress interface around the browser feature.
Sites need more robust token validation
Websites participating as verifiers also need to review how they parse Email Verification Tokens. Chrome delivers the token using the SD-JWT format, and implementations that simply split the current token into two JWT values may break if selective disclosures are introduced later.
Chrome recommends parsing the complete SD-JWT structure according to the specification and validating details such as the audience, nonce, hashes, and signatures. Email address comparisons should also be case-insensitive because a provider may return a canonicalized address with different capitalization from the value originally entered in the form.
Chrome 153 changes how providers receive verification requests
The most important compatibility change affects email providers. Starting with Chrome 153, issuance requests switch from an application/x-www-form-urlencoded POST containing a request_token to an application/json request containing the email address and protected by HTTP Message Signature headers.
Providers testing the feature can temporarily support both formats while Chrome versions transition. The response format remains unchanged. Email Verification is also still limited to desktop through Chrome 152, while Android support remains under exploration, and third-party origin trials are not currently supported for this feature.
IMPORTANT: Chrome 153 introduces a breaking change for participating email providers by replacing the previous issuance request format with JSON and HTTP Message Signatures. Provider endpoints should be updated before relying on Chrome 153 traffic.{alertWarning}
Daisuki's Take: What This Means for Web Designers
The design value of browser-based email verification is mostly about reducing interruption. Account creation and recovery flows often lose momentum when users must switch to an inbox, find a message, and return to the original website before continuing.
The new progress indicator is also a good example of browser functionality taking responsibility for part of the interaction feedback. Designers still need a reliable fallback flow, but they may not need to recreate every verification state manually when Chrome can complete the process successfully.
We would treat Email Verification as an enhancement rather than a replacement for existing account flows while the proposal remains in an origin trial. The UX opportunity is strong, but browser support, provider participation, protocol changes, and fallback behavior still need to be tested carefully before a site depends on it.
Sources and Recommended Links
- Email verification updates, August 2026 | Chrome for Developers Official Blog
- Test the Email Verification Protocol with an origin trial | Chrome for Developers Official Blog
