demo · v150
Token Inspector
Once the form submits, the relying party gets a signed JWT in the hidden email-verification-token field. This page decodes one and shows the claims you'd be verifying server-side — issuer, subject email, audience, expiry, and nonce.
Origin trial. Paste a real EVP token below, or click "use sample token" to populate a representative one (signature won't validate — it's only here to show structure).
header
decode a token to see header.
payload (claims)
decode a token to see claims.
signature
decode a token to see signature.
// Relying-party server pseudo-code:
const token = req.body.token; // hidden input
const { header, payload } = decodeJwt(token);
assert(payload.iss === "https://mail-provider.example");
assert(payload.aud === "https://relying-party.example");
assert(payload.exp > Date.now() / 1000);
assert(payload.nonce === serverIssuedNonce);
assertSignature(token, providerJwks); // RS256 / ES256
// Trust this email belongs to the user signing up.
createAccount({ email: payload.sub });
what to verify server-side
The browser only handles the user-facing autofill flow. Issuer / audience / expiry / signature checks are entirely your responsibility on the server. The token's nonce is the same value your form rendered as <input nonce> on the autocomplete field — that's how you bind the verified email to this session.
see also
- Email Verification Protocol — feature index
- Verification Flow — companion demo
- ChromeStatus entry
- EVP explainer
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗