JWT decoder and signature verifier

About this tool

Read a three-part JWT as formatted Header and Payload JSON, or explicitly verify its signature with a public key you trust. Choose RS256, PS256 or ES256 yourself. Local WebCrypto verification reports the signature separately from exp, nbf, iat, issuer and audience checks. Decoding alone never authenticates a token.

Examples

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwiaWF0IjoxNzAwMDAwMDAwfQ.fskbbfT8Y-3vjXSxYDdc-fa23GdUmhivjVOFM9NWx8w

{
  "sub": "user-42",
  "iat": 1700000000
}

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoi5L2g5aW9IC8g5pel5pys6KqeIn0.6D1s9ZGSyIcSKLrHkt0c-TQ5z-EXQBbca1LyIGKjSD5nTsgjVxvxt9YDGLSLWJ_hp4GxYVemJchQ7XfXNV6xmQ

{
  "name": "你好 / 日本語"
}

Common errors and checks

• A pasted Bearer prefix, extra dot or missing segment prevents parsing; supply only the three-part token.
• Standard Base64 characters + and /, padding =, invalid UTF-8 or non-object JSON in Header/Payload may fail. JWT uses unpadded Base64url.
• Readable JSON, a future exp value, or an alg label does not prove authenticity or authorization.

Limits and notes

• —Decoding keeps the original three-part UTF-8 JSON-object workflow, including display of an empty or altered signature. Verification applies stricter input and key checks. Five-part encrypted JWE, detached payloads and non-object Header/Payload are unsupported.
• —Verification supports only RS256 and PS256 with 2048–4096-bit RSA public keys, or ES256 with a P-256 EC public key. PS256 uses a 32-byte salt. The selected algorithm must match alg. HMAC shared secrets, private keys and alg none are rejected; the legacy HS256/HS512 examples below are decoding examples only.
• —Paste a single public JWK or SPKI BEGIN PUBLIC KEY PEM. JWK sets, certificates and other PEM types are unsupported. jku, x5u, embedded jwk, x5c, crit and b64 headers are rejected; no remote key lookup or token-directed key selection occurs. Verification accepts only alg, typ, cty and kid header members; kid is a label, not a key lookup. JWK metadata must agree with the selected algorithm and signature verification use. Duplicate JSON names, invalid Unicode and non-canonical Base64url are rejected rather than normalized.
• —Claim checks are separate from the signature. NumericDate uses Unix seconds, not milliseconds. Missing or skipped checks are not passes. A matching signature does not establish the owner of an untrusted key, a user’s identity, authorization or revocation status.
• —Verification limits: token 64 KiB, public-key text 16 KiB, JSON depth 16 and 4096 nodes, with a 5-second disposable worker deadline. Inputs are processed locally, without upload or storage. Prefer synthetic tokens; real bearer tokens and their claims can contain sensitive information. Encoded segments are separately limited to 4096 Header, 60000 Payload and 1024 signature characters. Expected issuer/audience text is limited to 2048 characters each; clock tolerance must be between 0 and 300 seconds. NumericDate must be a finite JSON number within the safe numeric range; strings and null fail. Missing time claims are reported as missing, and iat is informational, not a freshness policy.

Frequently asked questions

Related tools