What a JWT contains
A JSON Web Token has three parts separated by dots: header.payload.signature. The header and payload are Base64URL-encoded JSON — readable by anyone. The signature is what proves the token wasn't tampered with, and verifying it requires the signing key. This tool shows you the first two parts and leaves the signature untouched.
Common payload claims
sub— subject (usually the user ID)iat— issued-at time (Unix seconds)exp— expiry time (Unix seconds)nbf— not-valid-before timeiss/aud— issuer and audience
FAQ
Is my token sent anywhere?
No. The token is decoded locally in your browser and never leaves the page.
Why isn't the signature verified?
Verification requires the secret or public key that signed the token, which only your backend should hold. This tool intentionally stays a decoder.
Can I read an encrypted JWT (JWE)?
No. Standard JWTs are signed, not encrypted, so their payload is readable. A JWE is encrypted and cannot be read without the key.
Decoding is not verifying
This is the single most important thing to understand about JWTs. Because the payload is only Base64URL-encoded, anyone can read it and, just as easily, forge a new one with whatever claims they like. What stops a forged token from being accepted is the signature: your backend recomputes it with the signing key and rejects the token if it doesn't match. So decoding a token — what this tool does — tells you what it claims, never whether those claims are trustworthy. Never make an authorization decision based on a decoded payload alone; always verify the signature on the server first.
Why the payload isn't a secret
Since anyone holding a JWT can read its payload, never put anything sensitive in it — no passwords, no private personal data, no API secrets. Treat the payload as public information that merely happens to be tamper-evident. If you need to hide the contents rather than just prove they weren't altered, you want encryption (a JWE), not a normal signed JWT.
Reading expiry with confidence
The exp and iat claims are Unix timestamps in seconds, which is why "is this token expired?" is one of the most common reasons to decode one. A token whose exp is in the past will be rejected by a correct server no matter what else it contains. If a request is failing with an auth error, decoding the token and checking exp against the current time is the fastest first diagnostic — often the token is simply stale and needs refreshing.
Why does my token have only two parts?
An alg: none token has an empty signature, so it can look like it's missing a part. These are unsigned and should never be trusted; a normal signed JWT has all three sections.
Does decoding change or consume the token?
No. Decoding is read-only and offline — the token is unchanged and can still be used exactly as before.