JWT Decoder
Decode JSON Web Tokens and read their claims
JWT Decoder tool
JWT Decoder: key facts
- What it does
- Decode JSON Web Tokens and read their claims
- Category
- Developer Tools
- Cost
- Free, with no account, sign-up, or install.
- Your data
- Runs entirely in your browser — the files and text you enter are never uploaded to a server.
- Last reviewed
- . Report an incorrect result.
What this tool is for
A JSON Web Token looks like one long, unreadable string, but it is really three Base64URL-encoded sections — header, payload, and signature — joined by dots. The JWT Decoder splits that string apart and shows you the JSON inside each section in a readable, indented form.
Developers lean on it while debugging authentication: checking which claims an identity provider actually issued, confirming a token has not silently expired, or comparing the payload from a failing request against one that works. Because it decodes any well-formed token, it is just as useful for inspecting access tokens from an OAuth flow as it is for reading a session token pulled from local storage.
One detail worth understanding: decoding is not the same as verifying. This tool reveals what a token contains; it does not check that the signature is authentic, because that requires the issuer's secret or public key.
How to use the JWT Decoder
- Paste your token into the "JWT Token" field — it should be the full string with two dots separating three parts.
- Click Decode.
- Read the Header section to see the signing algorithm and token type.
- Read the Payload section for the claims; any "exp" (expires) and "iat" (issued at) timestamps are automatically shown in human-readable local time.
- Use the copy button on the header or payload to grab the formatted JSON, and note that the Signature is shown as raw Base64 since it cannot be decoded without the key.
Decoding is not verifying
A JSON Web Token is three base64url-encoded segments separated by dots: a header describing the algorithm, a payload carrying the claims, and a signature. This tool splits on the dots, converts the base64url alphabet back to standard base64, decodes the first two segments, and parses them as JSON.
It does not check the signature, and that is the single most important thing to understand about it. Base64 is an encoding, not encryption — anyone holding a token can read its payload, and this tool simply does so conveniently. A decoded token proves nothing about who issued it or whether it has been altered.
Verification requires the signing key and a cryptographic check, which is the server's job on every request. A client that reads claims out of a token without verifying it is trusting data an attacker can rewrite freely.
- The header typically reports the algorithm and token type, for example HS256 and JWT.
- Standard payload claims include the issuer, subject, audience, and expiry as a numeric timestamp.
- The third segment is shown as-is, since verifying it would require the key.
What the JWT Decoder gets right
- Tokens are decoded in your browser with the native atob function — the token never leaves your device, which matters because JWTs often carry session identity.
- Expiry and issued-at timestamps are converted from Unix epoch to readable dates automatically, so you can see at a glance whether a token is stale.
- Header, payload, and signature are shown separately, each with its own copy button, instead of as one undifferentiated blob.
- It is honest about its limits: it shows the signature without pretending to validate it, so you are never misled into trusting an unverified token.
Never paste a live token, and what to check server-side
Treat a token as a credential, because that is what it is. A bearer token grants whatever access its claims describe until it expires, so pasting a live production token into any web page — this one included — is equivalent to pasting a password. Use expired tokens, tokens from a development environment, or tokens you have deliberately invalidated. Everything here happens in your browser and nothing is transmitted, but the habit is worth keeping regardless.
On the server side, verification means more than a valid signature. Check that the algorithm matches what you expect rather than trusting the header — accepting the header's own algorithm claim is the classic vulnerability, including the none algorithm and confusion between symmetric and asymmetric signing. Then validate expiry, not-before, issuer, and audience.
Two design points that follow from readability. Do not put anything confidential in a payload, since it is plainly visible to the holder. And because tokens cannot be revoked before expiry without extra machinery, short lifetimes with refresh tokens are the standard approach.
Frequently Asked Questions
Does this tool verify the token's signature?
No. It decodes and displays the contents of all three parts but does not verify the signature, which would require the secret key (for HMAC) or public key (for RSA/ECDSA). Treat the decoded output as informational, not as proof the token is valid.
Is it safe to paste a real access token here?
Decoding happens entirely in your browser and the token is never sent anywhere. That said, anyone with a valid token can use it until it expires, so avoid pasting production tokens into any tool on a shared or untrusted computer as a general precaution.
Why does it say "Invalid JWT format"?
A JWT must have exactly three sections separated by dots. That error means your input has the wrong number of parts — often because a dot is missing, the string was truncated when copied, or you pasted something that is not actually a JWT.
What do "exp" and "iat" mean in the payload?
"iat" is the time the token was issued and "exp" is the time it expires, both stored as Unix timestamps. This decoder converts them to readable dates so you can immediately tell when a token was created and whether it is still valid.
