How it works
A JSON Web Token is three Base64URL segments joined by dots: header, payload and signature. The header describes the token type and signing algorithm; the payload carries the claims such as sub, iat, exp and nbf; the signature is the cryptographic proof produced by the issuer. This tool splits the token, converts the Base64URL alphabet, and pretty-prints the first two segments as readable JSON.
The info panel interprets the standard time claims for you: issued-at, expiration and not-before are rendered as local dates, and an expired token is flagged in red so you do not have to compare epoch numbers in your head. The algorithm and type from the header are shown alongside the subject claim when present.
Decoding is not verifying. Reading a JWT's contents requires no secret, because the payload is only encoded, not encrypted. This tool deliberately does not validate signatures: it cannot tell you whether a token is trustworthy, only what it says. Treat the contents as untrusted claims until your backend checks the signature against the issuer's key.
Because everything runs locally with atob and JSON.parse, you can safely inspect production tokens that contain user IDs, emails or internal claims. Pasting a token here sends nothing over the network.
Worked example
Decode a token whose payload contains {"sub":"user-42","iat":1709000000,"exp":1709003600}. The tool renders the claims and computes the dates.
| Segment | Content | What you learn |
|---|---|---|
| Header | {"alg":"HS256","typ":"JWT"} | Which algorithm the issuer used and that this is a JWT. |
| Payload | sub, iat, exp | Who the token concerns and its validity window. |
| Signature | Opaque bytes | Present but not verified — trust still depends on the backend check. |
- Paste the token: Copy the compact JWT without any Bearer prefix or surrounding quotes.
- Decode it: The tool splits the three segments and prints header and payload as JSON.
- Check the info panel: Read iat, exp, nbf as dates and note the algorithm and subject.
- Verify server-side: Confirm the signature in your backend before trusting any claim.
With exp at 1709003600, the panel shows the local expiration time and marks the token EXPIRED in red once that moment has passed. The one-hour gap between iat and exp is visible at a glance.
Common errors and edge cases
- “Must have 3 parts.” A JWT has exactly two dots. Pasting a truncated token, or one wrapped in quotes or a
Bearerprefix, triggers this error — strip the extras first. - Base64URL confusion. Segments use
-and_instead of+and/. The tool converts them automatically; a generic Base64 decoder may not. - Expired ≠ invalid. An expired token still decodes fine. Expiration is a claim about time, not a decoding failure.
- Trusting the payload. Anyone can forge a token body. Never authorize a user from a decoded payload without server-side signature verification.
- Clock skew. A token can appear expired or not-yet-valid because your machine's clock differs from the issuer's. Check
nbfand your system time.
Code equivalents
Decoding is just Base64URL plus JSON in every language; verification is the part that needs the issuer's key and a real JWT library.
| Language | Example |
|---|---|
| JavaScript | JSON.parse(atob(part.replace(/-/g,'+').replace(/_/g,'/'))) decodes one segment. |
| Python 3 | jwt.get_unverified_header(token) and jwt.decode(token, options={'verify_signature': False}) with PyJWT. |
| Verify properly | jwt.decode(token, key, algorithms=['HS256']) — always pin the algorithm list, never read it from the token. |
Related tools
Frequently asked questions
Does this tool verify the JWT signature?
No, deliberately. Decoding only reads the encoded claims. Verification requires the issuer's secret or public key and must happen in your backend with a trusted JWT library.
Is it safe to paste a production token here?
Yes for decoding: everything runs in your browser and nothing is transmitted. Still treat tokens as secrets — do not paste them into third-party websites you do not control.
Why does my token show as expired?
The exp claim is compared with your device's current time. If it looks wrong, check your system clock and remember that expired tokens still decode normally.
What is the difference between iat, nbf and exp?
iat is when the token was issued, nbf is the earliest time it should be accepted, and exp is when it stops being valid. All three are seconds since the Unix epoch.
Can a JWT be encrypted instead of signed?
Yes — that is JWE, and its payload is not readable without the decryption key. The compact three-part tokens you usually see are JWS: signed, not encrypted.
Privacy note
All processing happens in your browser. The values you enter never leave your device and are never transmitted to ToolPlex.