What changed
On August 13, Chrome documented a breaking change for email providers participating in the Email Verification origin trial. Chrome 152 and earlier POST an application/x-www-form-urlencoded issuance request containing a request_token. From Chrome 153, the browser instead sends application/json containing only the email address, together with Content-Digest, Signature, Signature-Input and Signature-Key headers based on HTTP Message Signatures. Chrome recommends providers support both formats during the transition. On August 18, the experiment owner also clarified that the origin trial is planned to continue through Chrome 156 rather than ending at 153, with Android implementation work planned for 154–156.
Why it matters
Email Verification is trying to remove the usual magic-link or OTP email hop by letting a browser obtain cryptographic proof of address control directly from an email provider. That makes the provider endpoint part of a multi-party protocol spanning browser, verifier site and mail service. A wire-format change therefore has concrete compatibility consequences: providers that switch only to the new request will break older Chrome clients, while providers that keep only the legacy path will fail on Chrome 153+. The extended origin trial also means implementers should treat this as an evolving experiment, not a stable cross-browser web standard.
The provider request contract is changing
Chrome 153 replaces the earlier form-encoded issuance request with a JSON request containing the email address and HTTP Message Signature headers. The response remains an application/json body containing an issuance_token. For providers, the practical migration boundary is the request parser and signature-verification path rather than the token response format.
Dual-format support is the safest transition
Chrome explicitly recommends switching on Content-Type and accepting both the legacy application/x-www-form-urlencoded request and the new signed application/json request while multiple browser versions are in use. A provider that implements only the new path will cause verification to fail for Chrome 152 and earlier; leaving only the old path breaks 153 onward.
Verifier sites have their own correctness work
Chrome also tightened guidance for sites consuming verification tokens. Tokens use the SD-JWT format, so implementations should parse the structure with an SD-JWT library rather than assuming the current token always contains exactly two JWT components. Verifiers should also compare returned email addresses case-insensitively.
This is still an origin trial, not a settled standard
The browser-side proposal remains experimental. The original Blink intent described a desktop origin trial, and an August clarification extended it through Chrome 156 with Android work planned for 154–156. The backend protocol is an active IETF Internet-Draft, while browser-facing work sits in WICG. Implementers should expect further iteration and preserve fallback flows such as ordinary email OTP or magic-link verification.