JWT Decoder
Runs in your browserDecode a JSON Web Token and inspect its header, payload and expiry.
Token
What is a JWT Decoder?
A JSON Web Token is three Base64url-encoded segments joined by dots: a header describing the signing algorithm, a payload carrying the claims, and a signature. The first two segments are encoded, not encrypted — anyone holding the token can read them. A JWT decoder simply performs that decoding and pretty-prints the result, which is what makes it useful as a JWT debugger: you can inspect exactly what a token claims without writing a script to do it.
Decoding is not verification. This tool shows you what a token claims; it does not check whether the signature is genuine, because doing so requires the issuer's secret or public key. A token with a forged payload and a broken signature decodes exactly as cleanly as a valid one. Signature verification belongs on your server, never in a browser tool.
Because the payload is readable by anyone who intercepts it, a JWT should never carry passwords, full payment details or anything else you would not put in a log line.
How to use it
- Paste the token into the input box. A leading "Bearer " prefix is stripped automatically, so you can paste straight from an Authorization header.
- The header and payload decode as you type. No button to press.
- Check the Validity panel to see the JWT's expiry status at a glance — it reads the exp, iat and nbf claims and shows how long until the token expires, or how long ago it did.
- Read the standard claims — iss (issuer), sub (subject), aud (audience), jti (token ID) — alongside any custom claims your application added.
Examples
A decoded payload
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c{
"sub": "1234567890",
"name": "Ada Lovelace",
"iat": 1516239022
}A token with no exp claim
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMTIyMzM0NDU1IiwibmFtZSI6IkdyYWNlIEhvcHBlciIsImlhdCI6MTcwMDAwMDAwMH0.not-a-real-signature{
"sub": "1122334455",
"name": "Grace Hopper",
"iat": 1700000000
}
Validity: No expiry claim — this token never expires on its own.A token with custom claims
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMTIyMzM0NDU1IiwibmFtZSI6IkdyYWNlIEhvcHBlciIsInJvbGUiOiJhZG1pbiIsIm9yZyI6InRvb2xzZWwiLCJpYXQiOjE3MDAwMDAwMDAsImV4cCI6MTcwMDAwMzYwMH0.not-a-real-signature{
"sub": "1122334455",
"name": "Grace Hopper",
"role": "admin",
"org": "toolsel",
"iat": 1700000000,
"exp": 1700003600
}
2 custom claims: role, orgFrequently asked questions
Is it safe to paste a real access token here?
Decoding happens entirely in your browser — the token is never sent over the network, logged or stored. That said, treat any live token as a password: prefer an expired or test token when you can, and rotate anything you have pasted into a tool you do not control.
Does this verify the signature?
No, and no browser tool can do so safely. Verification requires the signing secret or public key, and pasting a signing secret into a website would hand over the ability to mint valid tokens. Verify on your server with a maintained JWT library.
Why can anyone read my JWT payload?
Base64url is an encoding, not encryption. It exists to make binary-safe text, not to conceal it. The signature guarantees the payload has not been altered; it does not hide the payload. If you need confidentiality, use JWE or simply do not put the data in the token.
What do exp, iat and nbf mean?
They are timestamps in seconds since the Unix epoch. exp is when the token expires, iat is when it was issued, and nbf (not before) is the earliest time it may be accepted. This tool renders all three as local dates.
My token will not decode. What is wrong?
Check that you copied all three dot-separated segments — truncation during copy is the most common cause. Also confirm you have a JWT and not an opaque session token, which is a random string with no internal structure and nothing to decode. A token with five segments instead of three is usually a JWE (an encrypted token), which this tool can't decode without the recipient's decryption key.
What is alg:none and why is it dangerous?
It's a header value meaning the token isn't signed at all. It's dangerous because some JWT libraries have historically accepted an alg:none token as valid if the verifying code didn't explicitly reject it — effectively letting anyone forge a token with whatever claims they want. This tool flags it when present, but flagging it is only an observation about the token you pasted, not proof that any particular application is vulnerable to it.
Can I use this tool as a JWT debugger?
Yes — that's the main use case. Paste a token from a failing request, an Authorization header, or a local test, and inspect its header, claims and expiry status without writing a script or reaching for a CLI tool. It won't tell you why your server rejected a token (that needs verification, which happens server-side), but it will tell you exactly what the token itself contains.
How do I check when a JWT expires?
Decode it here and look at the Validity panel — it reads the exp claim and shows either how long until the token expires or how long ago it did, alongside the exact timestamp. A token with no exp claim has no time-based expiry at all, which the panel also states explicitly.
Can I use a JWT in an Authorization header?
That's the token's most common use — sent as Authorization: Bearer <token> on API requests. This tool strips a leading "Bearer " prefix automatically, so you can copy the full header value straight out of your network tab or a curl command and paste it in without editing it first.