JWT Decoder
How to use this JWT decoder
- Paste an encoded JWT into the left box.
- The header and payload decode automatically.
- Inspect the claims — useful for debugging auth issues.
What is a JWT?
A JSON Web Token is a compact, URL-safe way to represent claims between two parties. It has three parts separated by dots: header, payload, and signature.
Does this verify the signature?
No. This tool only decodes the header and payload so you can inspect their contents; it does not verify the signature, and you should never paste tokens containing real secrets into third-party tools.
Is it safe to decode a production JWT here?
Decoding happens locally in your browser and nothing is sent anywhere, but as a general habit, avoid pasting tokens from production systems into any third-party tool.
What does "exp" mean in the payload?
"exp" is the expiration time, a standard claim indicating when the token becomes invalid, expressed as a Unix timestamp.
How signature verification actually works
A JWT's signature exists to prove the header and payload haven't been tampered with since the token was issued, and understanding how depends on which algorithm was used, shown in the header's "alg" field. With a symmetric algorithm like HS256 (HMAC with SHA-256), the same secret key is used both to create the signature and to verify it, meaning both the issuer and anyone verifying the token must share that same secret. With an asymmetric algorithm like RS256 (RSA with SHA-256), the issuer signs using a private key, but verification uses a separate, publicly shareable public key — which is what makes RS256 the more common choice for tokens that need to be verified by multiple independent services, since none of them need access to the actual signing secret. Either way, verification means recomputing the signature from the header and payload and checking it matches what's attached to the token — something this decoder deliberately doesn't do.
Why decoding is not the same thing as trusting a token
This is the single most important thing to understand about JWTs: the payload of a JWT is only base64url-encoded, not encrypted, which means anyone who has the token — including someone who intercepted it in transit, or a browser extension with access to local storage — can read every claim inside it without needing the secret key at all. This is precisely why JWTs should never contain sensitive information like passwords or full credit card numbers in their payload, only identifiers and claims that are fine to be readable. Separately, and just as importantly, decoding a token's contents (which this tool does) proves nothing about whether that token is legitimate — an attacker can craft a JWT with any payload they want; only verifying the signature against the correct key confirms it was actually issued by a trusted party and hasn't been altered.
The standard claims worth knowing: iss, sub, aud, exp, nbf, iat
RFC 7519 defines a small set of standard, optional claim names that appear across most real-world JWTs, and recognizing them makes reading an unfamiliar token's payload much faster. "iss" (issuer) identifies who issued the token. "sub" (subject) identifies who the token is about, typically a user ID. "aud" (audience) identifies who the token is intended for, letting a service reject tokens meant for a different application. "exp" (expiration time) and "nbf" (not before) bound the window during which the token is valid, both as Unix timestamps. "iat" (issued at) simply records when the token was created. Beyond these standard claims, applications commonly add their own custom claims (roles, permissions, email) directly alongside them, since the payload is just a JSON object with no restriction on additional fields.
JWTs versus traditional session cookies — the real tradeoff
JWTs and traditional server-side session cookies solve the same underlying problem — remembering who a user is across requests — but with a fundamentally different tradeoff. A session cookie typically stores just an opaque ID, with all the actual session data kept server-side in a database, meaning the server can immediately invalidate a session by deleting that record. A JWT is self-contained — the server can verify it's valid without a database lookup at all, since everything needed is in the token itself — which is faster and scales better across distributed services, but comes at a real cost: a JWT issued with a long expiration can't be immediately revoked before that expiration without adding back some form of server-side tracking (a blocklist of revoked token IDs), which partially reintroduces the very statefulness JWTs were meant to avoid.
Limitations of this tool
This tool decodes a JWT's header and payload so you can inspect their contents locally in your browser — it deliberately does not verify the signature, since doing so safely would require you to provide the actual signing secret or key, which you should never paste into any third-party tool, including this one. It doesn't check whether a token has expired, doesn't validate that required claims are present, and doesn't warn about known JWT security pitfalls (like accepting a token with "alg: none"). Use it purely for inspecting and debugging a token's claims — actual verification belongs in your application's own backend code, using a trusted JWT library and your real signing key.