Decode and inspect JWT tokens. View header and payload as formatted JSON, check expiration, and see algorithm. All decoding happens in your browser — no tokens are stored or transmitted.
JSON Web Tokens (RFC 7519) are a compact, URL-safe way to represent signed claims between two parties. A JWT has three parts separated by dots: header, payload, and signature. The header and payload are Base64url-encoded JSON objects; the signature is a cryptographic signature over those two parts using the algorithm named in the header. This decoder parses the encoded parts so you can inspect the contents without running custom scripts.
The header usually contains the algorithm (e.g., HS256 or RS256), token type (typ: JWT), and optionally a key ID (kid). The payload holds claims such as sub (subject), exp (expiration), iat (issued at), iss (issuer), and aud (audience). The exp claim is a Unix timestamp in seconds — the decoder displays it in ISO format and indicates whether the token is expired.
This tool only decodes the token; it does not verify the signature. Never trust decoded claims without signature verification in a secure environment. Avoid pasting production tokens into unknown tools — this decoder runs entirely in your browser, but caution is warranted with sensitive data.
A browser-based JWT decoder is useful for quick inspection and debugging. It is the wrong tool when:
jsonwebtoken, jose, or PyJWT — never a web tool. /introspect endpoint (RFC 7662).jwt-cli, jose CLI, or a language-specific library — not a web page.sub, iss, aud, exp, and any custom claims your application has set.exp Unix timestamp to a human-readable date and indicates whether the token is currently valid or expired.Decoding is done entirely in your browser via client-side JavaScript — no token data is sent to any server or logged. That said, never paste a production access token into a tool you do not control. For production debugging, mint a throwaway token from a test account or use the tool in an incognito session after revoking the pasted token.
JWT tokens are Base64url-encoded — not encrypted. Anyone with the token can decode the header and payload and read every claim in plain text. The signature protects integrity (preventing tampering) but not confidentiality. If you need encrypted tokens, use JWE (JSON Web Encryption, RFC 7516), which wraps a JWT inside an encrypted envelope.
This is almost always clock skew between the issuing server and the machine running the decoder, or a very short `exp` TTL. Common causes: the issuer's system clock is off, `iat` is set in the future, the `exp` is expressed in milliseconds instead of seconds (JWT uses seconds since Unix epoch — RFC 7519 §2), or a proxy is caching an old token.
No. This is a decoder, not a verifier. Verifying a JWT signature requires the issuer's secret (HMAC) or public key (RSA/ECDSA) and must be done in a trusted environment, never in a shared tool. Use your framework's JWT library (`jsonwebtoken` in Node, `PyJWT` in Python, `jose4j` in Java) for verification.
Any RFC 7518 algorithm is decoded, because decoding does not depend on the algorithm — the tool reads the header's `alg` field and shows what the issuer claimed. Common values: HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA P-256), EdDSA (Ed25519). "none" is supported but flagged as unsafe per current IETF guidance.
Yes. OIDC ID tokens are JWTs with additional standardized claims (`iss`, `aud`, `sub`, `nonce`, `at_hash`, etc.). The decoder shows all claims regardless of type. For access tokens, you may see opaque reference tokens instead of JWTs — those cannot be decoded because they are random identifiers, not encoded structures.
The `kid` header identifies which key in the issuer's JWKS (JSON Web Key Set) was used to sign the token. During verification, your library fetches the JWKS (usually from `{issuer}/.well-known/jwks.json`) and picks the matching `kid`. If `kid` is missing or does not match any key in the set, verification fails.