JWT Decoder – Decode and Inspect JWT Tokens Online
Decode any JSON Web Token instantly. Inspect header algorithm, all payload claims with descriptions, expiry status, and signature info. No secret key required. Runs entirely in your browser.
How This JWT Decoder Works
A JSON Web Token is a Base64url-encoded string split into three parts by dots: the header, the payload, and the signature. This JWT decoder splits the token on those dots and decodes each part with Base64url decoding, then parses the result as JSON. No secret key or public key is needed to decode the header and payload because they are not encrypted, only encoded.
The tool shows each payload claim with a plain-English description based on the IANA JWT Claims Registry (RFC 7519). Time-based claims like exp, iat, and nbf are shown as human-readable dates alongside their Unix timestamps, with a relative time indicator (e.g. “expires in 2 hours”). The expiry badge at the top tells you at a glance whether the token is currently valid, expired, or has no expiry set.
The signature section explains that verification requires the secret or public key — this is by design. The decoder is intentionally read-only, making it safe for inspecting tokens in development, debugging auth issues, and understanding JWT structure. Your token never leaves your browser.
What this tool does
How to use it
Paste token
Paste your JWT token (with or without the “Bearer ” prefix) into the text area.
Click Decode
Click Decode JWT. The tool auto-decodes when it detects a valid three-part token as you type.
Inspect claims
See header algorithm, all payload claims with descriptions, and expiry status clearly labeled.
View raw JSON
Toggle “Show raw JSON” on any section to see the raw decoded JSON for copying or analysis.
Questions About the JWT Decoder
No, and that is intentional. JWT signature verification requires the secret key (for HS256/HS384/HS512) or the public key (for RS256/ES256 and other asymmetric algorithms). This tool decodes the header and payload — which are Base64url-encoded, not encrypted — so you can inspect the claims. To verify a token, use your server-side library: jsonwebtoken in Node.js, PyJWT in Python, or java-jwt in Java.
The decoding runs entirely in your browser — your token is never sent to a server. That said, production JWTs containing active user sessions should be treated as sensitive credentials. For real tokens with live expiry, be cautious about pasting them anywhere. Use the “Load Example” button if you just want to explore the tool without using a real token.
The decoder reads the algorithm from the header (alg claim) and displays it, but the algorithm does not affect decoding of the header and payload — only signature verification depends on it. The tool works with any JWT regardless of algorithm: HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, and so on. It also handles “none” algorithm (unsigned) tokens.
RFC 7519 defines registered claims: sub (subject, usually the user ID), iss (issuer, usually your auth server URL), aud (audience, the intended recipient), exp (expiration time), iat (issued at), nbf (not before), and jti (a unique ID for the token). Beyond these, OIDC adds claims like email, name, given_name, picture, and locale. Custom claims like roles, scope, and permissions are application-specific and vary by implementation.
The exp claim is a Unix timestamp (seconds since January 1, 1970 UTC). If the server that issued the token has a clock skew relative to your local machine, or the token has a very short TTL (common in test environments), the token may appear expired even if it was just issued. Also check that you are reading the right token — many auth flows issue both an access token (short-lived) and a refresh token (long-lived) and these are easy to mix up.
A traditional session cookie contains only an opaque session ID — the server looks up the session data in a database on each request. A JWT is self-contained: all claims are embedded in the token itself, so the server only needs the key to verify the signature, with no database lookup required. JWTs are stateless and scale well horizontally, but cannot be invalidated before they expire without extra infrastructure (a blocklist). Session cookies are stateful but trivially revocable.
No. A JWE (JSON Web Encryption) token has five parts separated by dots and the payload is actually encrypted, not just encoded. Decoding it requires the private key or shared symmetric key used for encryption. This tool only handles standard JWTs (JWS — JSON Web Signature), which have three parts and an encoded (not encrypted) payload. If you paste a five-part token, the tool will report a format error.
As this tool demonstrates, decoding a JWT payload requires no key at all — it is just Base64url encoding, which anyone can reverse. The signature only proves the token was issued by a specific party and has not been tampered with; it does not hide the payload content. Passwords, personal identification numbers, full credit card numbers, and other highly sensitive data should never appear in a JWT payload because any party who receives the token can read the claims. Store such data server-side and reference it by a safe identifier.