JWT Decoder
Decode JSON Web Tokens (JWT) to view header and payload.
About JWT Decoder
A JSON Web Token is three base64url segments joined by dots: a header naming the signing algorithm, a payload of claims, and a signature over the first two. Paste one above and the header and payload are decoded and indented, with the signature shown as it arrived.
What the decoding actually involves
Each segment uses base64url rather than ordinary Base64, so hyphens stand in for plus signs, underscores for slashes, and the trailing equals signs are dropped. The tool restores those substitutions, pads the length back to a multiple of four, decodes the bytes as UTF-8 and parses the result as JSON. That is the entire operation — no key, no network call, no state. It is exactly what a server does before it starts checking anything, which is the point: the claims are readable long before anyone has decided whether to believe them.
Claims worth checking first
When an API returns 401 and the token looks fine, four registered claims explain most of it. exp in the past is an expired token. nbf in the future means a clock skew between issuer and verifier. aud that does not name the API you are calling is the single most common cause of a rejection that feels inexplicable — an access token minted for one audience simply is not valid at another. And iss must match the issuer your verifier was configured with, tenant path and trailing slash included.
Debugging workflow
Copy the token out of the Authorization header rather than from application state, and strip the Bearer prefix. If the payload is not what you expected, check whether you are holding an ID token where an access token was needed — they come from the same login and look alike, but only one is meant to authorise an API call. When verification fails server-side, look at kid in the header, because a rotated signing key is a frequent cause.
Handling tokens responsibly
Decoding happens in this tab and no request is made, which the Network panel will confirm. Even so, a live access token is a bearer credential: anyone who obtains it can act as you until it expires. Prefer a token from a staging environment, and if you do paste a production one, treat it as disclosed and let it expire rather than reusing it. To read the timestamps in the payload, the Timestamp Converter turns those integers into dates.
Header And Claims, Pretty-Printed
The first two segments are base64url-decoded as UTF-8 and re-indented as JSON, so nested claims like scope arrays and custom namespaced keys are readable rather than one long line.
Decodes As You Type
There is no button. Paste or edit the token and the panels update on the next keystroke, which makes it quick to trim a stray quote or a wrapped line until the token parses.
Signature Shown, Never Checked
The third segment is displayed raw because validating it needs a key this page does not have and should not be given. Treat the payload as claims, not as verified facts.
Frequently Asked Questions
Why can anyone read my token without a password?
Because a standard JWT is signed, not encrypted. The header and payload are base64url — an encoding, not a cipher — so anyone holding the token can read them. The signature stops the contents being changed undetected; it does nothing to keep them private. Never put a password or anything else confidential in a claim.
Can this tool tell me whether the token is valid?
No, and that is deliberate. Verifying a signature requires the shared secret for HS256 or the issuer's public key for RS256 and ES256, and pasting a signing secret into a web page would be a far worse idea than the token itself. Use your library's verify function, or fetch the issuer's JWKS endpoint. This page answers a different question: what does the token actually claim?
What do exp, iat and nbf mean, and why are they big numbers?
They are NumericDate values — seconds since 1 January 1970 UTC, not milliseconds. exp is when the token stops being accepted, iat when it was issued, and nbf the earliest moment it may be used. This page prints them as raw integers rather than converting, so paste the number into the Timestamp Converter to read it. A token that appears to expire in 1970 usually means someone wrote milliseconds into a seconds field.
My token will not decode. What is wrong with it?
The tool needs exactly three dot-separated segments whose first two are base64url-encoded JSON; anything else shows Invalid JWT Token. Five segments means you have a JWE, an encrypted token whose payload is genuinely unreadable without the key. Fewer than three, or a segment that decodes to something that is not JSON, is usually a copy-and-paste problem: a line break inserted by a terminal, a leading "Bearer " left on the front, or surrounding quotes taken from a JSON response.
Should I trust the alg field in the header?
Not for anything. The header travels with the token and is under the sender's control, so an attacker can rewrite alg to none and strip the signature, or change RS256 to HS256 and sign with the public key as though it were a shared secret. Both were real vulnerabilities in widely used libraries. A verifier must fix its accepted algorithms in advance rather than reading the choice out of the token.
How long should the signature segment be?
Its length is a quick clue to the algorithm. HS256 produces 32 bytes, which is 43 base64url characters. ES256 produces 64 bytes, or 86 characters. RS256 produces 256 bytes, or 342 characters. So a 43-character segment on a token you expected to be RS256-signed is worth investigating, and an empty third part means the signature was stripped entirely.