JWT Decoder & Verifier

Decode, validate, and verify JWTs locally

All processing is local. Remote JWKS fetch is disabled by default — enable explicitly to fetch over HTTPS from an allow-listed domain.

Token Input & Status

Ready

Decoded Details

Paste a token to decode its header, payload, and timeline.

Keys & Actions

Verification & Decryption

Verification

Decryption

For JWE tokens. Paste the matching private key (RSA-OAEP / ECDH-ES) or password (PBES2). Or use the key already selected in Keys & Actions.

Remote JWKS

Utilities

Base64Url

PEM ↔ JWK

JWT Decoder & Verifier

Decode, validate, and verify JWTs locally

Features

  • Decode JWS (signed) and JWE (encrypted) tokens — compact serialization parsed to header + payload + signature, with claim extraction (iss/aud/exp/iat/nbf/sub/jti) and validity timeline
  • Signature verification with HS256/384/512 (HMAC), RS256/384/512 (RSA PKCS#1), PS256/384/512 (RSA-PSS), ES256/384/512 (ECDSA), EdDSA (Ed25519), and the explicit "none" algorithm — same engine the JWKS-aware backend uses
  • Decryption support for JWE: A128GCM, A192GCM, A256GCM (AES-GCM), A128CBC-HS256 / A192CBC-HS384 / A256CBC-HS512 (AES-CBC with HMAC), with key wrap via RSA-OAEP, RSA1_5, A128KW, A256KW, dir, ECDH-ES, PBES2-*
  • Multiple key sources: paste a JWK JSON, paste a PEM (public for verify, private for decrypt), paste a raw HMAC secret, or fetch a remote JWKS by URL (CORS-permitting endpoints)
  • Permalink sharing via URL hash + lz-string compression — share a token with a colleague without copy-pasting; private keys are deliberately excluded from the link
  • Diagnostics panel reports algorithm mismatches, weak HMAC keys, expired tokens, audience misses, issuer typos — same checks a production verifier should run
  • Sample tokens panel for testing: HMAC-signed sample with a published "your-256-bit-secret" plus example RSA and EC tokens with their keys — copy-paste-verify in under a minute
  • Pure client-side: parsing, verification, and decryption all use the WebCrypto API in your browser. Tokens never leave your tab, no key material is logged, works offline once cached

How to use

  1. Paste your JWT into the input. The header, payload, and signature segments parse immediately; the timeline shows iat/nbf/exp.
  2. Inspect the claims: confirm iss (issuer) matches expected, aud (audience) is correct, exp (expiry) is in the future, iat is reasonable.
  3. Open Keys & Actions, pick a key source (JWK / PEM / secret / JWKS URL), and load the key.
  4. Click Verify to run the signature check. The verification panel shows pass/fail per check (signature, expiry, audience, issuer, etc.) and per-algorithm diagnostics.
  5. For JWE, click Decrypt instead — the decrypted plaintext appears as parsed claims if it's a nested JWT, or as the raw content otherwise.
  6. Share state via permalink (only token, never keys) to discuss with teammates; use Copy Payload to export the claims to a ticket or report.

Tips & Best Practices

  • For production debugging, always use the JWKS URL flow rather than pasting keys manually — JWKS is the rotation-aware mechanism your IdP provides.
  • When verifying tokens that should never be signed with HS256, configure the verifier to reject HS256 explicitly; otherwise an attacker who learns the public RSA key as a "secret" can forge tokens.
  • The "none" algorithm should never appear in production logs. If the diagnostics show alg=none, the token is unsigned — treat as untrusted input.
  • For OAuth token introspection, decode the access_token here and verify against the IdP's JWKS; for refresh tokens, the format is provider-specific (sometimes opaque).
  • Use the permalink to share verification setups with teammates — they get the same token in the same state without you paste-bombing them.

FAQ

Is my token sent to your server?

No. JWT parsing, signature verification, and decryption all happen via the browser's WebCrypto API. The permalink feature compresses ONLY the token into the URL hash; private keys and HMAC secrets are deliberately excluded so a shared link can't leak credentials.

Which signature algorithms are supported?

HS256/384/512 (HMAC SHA-2), RS256/384/512 (RSASSA-PKCS1-v1_5), PS256/384/512 (RSA-PSS), ES256/384/512 (ECDSA over NIST curves), EdDSA (Ed25519). The dangerous "none" algorithm is supported for debug but always shown as a warning — production verifiers should reject it.

What encryption algorithms can the tool decrypt?

Content encryption: A128/192/256GCM, A128CBC-HS256, A192CBC-HS384, A256CBC-HS512. Key management: RSA-OAEP, RSA-OAEP-256, RSA1_5 (insecure, supported for debug), A128KW, A192KW, A256KW, dir, ECDH-ES + variants, PBES2-HS256+A128KW + variants. Coverage matches RFC 7518 (JWA).

Why does my JWKS fetch fail with CORS errors?

JWKS endpoints must respond with Access-Control-Allow-Origin: * (or your specific origin) for browser fetches to work. Most OIDC providers (Auth0, Okta, Google, Keycloak) do; some custom or internal IdPs don't. As a workaround, paste the JWK JSON directly from the JWKS URL.

What does the diagnostics panel check?

Algorithm not "none"; signature actually verifies against the key; exp claim in the future; nbf claim in the past; iat claim reasonably recent (not far-future); aud matches expected; iss matches expected; HMAC key length meets RFC 7518 minimum (32+ bytes for HS256). Each finding includes the spec reference.

What happens with an expired token?

The signature still verifies (assuming the key matches) — the cryptographic check is independent of time. The timeline panel highlights the exp boundary in red; the diagnostics include an "expired" finding. The decision to reject an expired token is the relying party's responsibility, not the cryptographic primitive's.

Why is HS256 with a short key dangerous?

HS256 is HMAC-SHA-256. The RFC 7518 minimum key length is 32 bytes (256 bits) of entropy. Shorter keys are vulnerable to brute force — and the most common bug in JWT-using applications is signing with a human-typed "secret-123" or "your-secret-key" string. The diagnostics flag short keys explicitly.

Can I export verified claims as a JSON document?

Yes. The Copy Payload button serializes the decoded payload as pretty-printed JSON ready to paste into a ticket, OAuth debugging session, or test fixture. Optional: export the diagnostics report (algorithm details, key info, validity checks) alongside.