JWT Decoder — Decode JWT Tokens to View Header and Payload
Decode JWT tokens to view header and payload claims. Base64-decode only, no signature verification — runs in your browser, your token never leaves your device.
JWT Decoder
Decode JWT tokens to view header and payload. Works entirely in your browser — your tokens never leave your device.
JSON Web Tokens are the most common authentication format on the web. Every OAuth2 flow, every OpenID Connect session, every API token in a modern application is a JWT — three Base64URL-encoded segments joined by dots, carrying a header, a payload of claims, and a cryptographic signature. The header and payload are not encrypted; they are base64-encoded, which means anyone who has the token can decode them. The security guarantee is not secrecy of the payload — it is the signature, which proves that the payload was issued by a trusted authority and has not been tampered with. A JWT decoder lets you read the header and payload claims, which is the first step in debugging any authentication flow.
The security warning that every JWT decoder should show: decoding is not verifying. The decoder reads the payload claims — who issued the token, when it expires, what permissions it carries — but does not check the signature. A token that decodes correctly could have been forged if the signature is not valid. Never use a decoded JWT as proof of authentication or authorization unless the signature has been verified with the correct secret key or public key. This decoder runs in your browser and never sends your token to a server, so the decoded claims are visible only to you — but they are still not proof of anything.
The most common reason to decode a JWT is to check whether it has expired. The exp claim is a Unix timestamp; the decoder shows the human-readable expiry date and highlights whether the token has already expired. The second most common reason is to inspect custom claims — application-specific data that the token issuer embeds in the payload, like a user ID, a role, a tenant identifier, or a permission set. The decoded payload is the source of truth for what the token claims to represent. Whether those claims are actually valid is a question for the verifier.
How to use
Paste your JWT
Drop a JWT string (three Base64URL-encoded segments separated by dots) into the input. The decoder splits the token on the dot delimiter and decodes the header and payload.
Inspect the claims
The header and payload decode to JSON. Common claims (`iss`, `sub`, `aud`, `exp`, `iat`, `nbf`, `jti`) are highlighted with their RFC 7519 descriptions. The `exp` claim shows the human-readable expiry time in your local timezone.
Copy the decoded JSON
Copy the header or payload JSON to your clipboard. Use the decoded JSON to debug token contents, inspect custom claims, or check the expiry time before making an API call.
Frequently asked
Why does this NOT verify the signature?
Signature verification requires the secret key or public key that signed the token. This decoder reads the header and payload — which are base64-encoded, not encrypted — and shows their contents. Never trust a decoded JWT without also verifying its signature, which requires the key and a backend service.
Is my JWT sent to a server?
No. The decoding runs in your browser with no network requests. The token stays on your device. This is the fundamental difference between a client-side JWT decoder and the dozens of websites that decode your token by sending it to their server.
What does the 'exp' claim mean?
The `exp` (expiration time) claim is a Unix timestamp (seconds since 1970-01-01T00:00:00Z). After this time, the token should be rejected by the verifying server. The decoder shows the expiration date in your local timezone so you can see at a glance whether the token has expired.
Can it handle encrypted JWTs (JWE)?
No. JWEs are encrypted and cannot be decoded without the decryption key. The decoder handles only signed-but-not-encrypted JWTs (JWS). An encrypted JWT appears as five Base64URL segments instead of three — the decoder will report that it cannot parse the format.
What are the standard JWT claims?
RFC 7519 defines seven registered claims: `iss` (issuer — who created the token), `sub` (subject — who the token is about), `aud` (audience — who the token is for), `exp` (expiration), `nbf` (not before), `iat` (issued at), and `jti` (JWT ID — a unique identifier to prevent replay). The decoder highlights these with their RFC definitions.
Limitations
- No signature verificationThis is a decoder, not a verifier. A decoded JWT is not a trusted JWT — the payload claims could have been modified in transit if the signature is not verified. Always verify the signature with the correct key on a trusted backend before relying on the claims for authentication or authorization.
- No key discoveryThe decoder does not fetch JWKS endpoints or discover public keys from OIDC metadata. It reads the token itself — the key management is separate.
- No JWE supportEncrypted JWTs use a different format (JWE) with five segments. Paste a JWE into the decoder and it will refuse to parse it. Use a backend decryption library to handle encrypted tokens.
Platform notes
- macOS
- Use the browser tool to decode a JWT from the command line: `pbpaste` on macOS pastes the clipboard into the input field. For CLI-only work, `echo $TOKEN | cut -d. -f2 | base64 -d | jq` decodes the payload.
- Windows
- The browser tool decodes JWTs without any installation. For CLI-only work, PowerShell's `[System.Convert]::FromBase64String()` and `ConvertFrom-Json` decode the payload.
- Linux
- For CLI-only work, `echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .` decodes the payload. The browser tool is the right pick when you don't want to leave a token in the shell history.
- Web
- Runs entirely client-side. No network requests. Your token stays on your device. Use this tool when you receive a JWT in an email, chat, or support ticket and need to inspect it safely.