JWT Decoder
Read a token’s claims, and prove its signature · runs in this tab, never sent anywhere
Token
Signature
A JWT is encoded, not encrypted — anyone holding this token can read everything above without a key. Only a signature check tells you it is genuine and unaltered.
Claims
Paste a token into the Token panel and its claims are listed here, in plain words.
Header
Payload
How the JWT Decoder works
A JWT decoder that splits a token into its three parts, decodes the header and payload, and lists every claim in plain words — with expiry, not-before and issued-at shown as real dates rather than epoch seconds. Access tokens and ID tokens from an OAuth 2.0 or OpenID Connect provider are JWTs too, so they read here exactly the same way. It also verifies the signature: paste the shared secret for an HS algorithm or a public key for RS, PS or ES, and the check runs on your browser’s own WebCrypto. Neither the token nor the key is ever uploaded, and the key is never even saved to this browser.
Paste a token — with or without its Bearer prefix — and it splits into its three parts, coloured so you can see where each one ends. The header and payload are decoded to JSON, and the claims are listed again in plain words, with exp, nbf and iat shown as real dates and as how long ago or how far off they are.
Decoding a JWT is not verifying it. The first two parts are base64url, not encryption: anyone holding the token can read them, which is why a token is never a place to put a secret. Turn on Check the signature and paste the shared secret for an HS algorithm, or a public key for an RS, PS or ES one, and the signature is actually tested — HS256/384/512, RS256/384/512, PS256/384/512 and ES256/384/512, using the browser's own WebCrypto.
The key you paste is treated differently from every other input on this site: it is never written to localStorage and never restored on refresh. Nothing here — token or key — is uploaded, and there is no backend that could receive either.
Common questions
Is it safe to paste a real JWT into this decoder?
Yes. The token is decoded by JavaScript in your own tab and there is no backend to send it to — disconnect from the network and the decoder still works. That matters more for JWTs than for most data: a token is a live credential, and pasting one into a site that posts it to a server hands over whatever it grants.
Can it decode an access token, an ID token or a bearer token?
Usually, yes — those names say what a token is for, not how it is built. OAuth 2.0 and OpenID Connect define no format of their own, so the access token and ID token most providers issue are ordinary JWTs and decode here like any other. A Bearer prefix copied along with it out of an Authorization header is stripped for you, as are wrapping quotes and stray line breaks. Refresh tokens are the common exception — see the next question.
My access token will not decode. What is wrong?
It is most likely an opaque token rather than a JWT. Nothing in OAuth 2.0 requires an access token to be readable by the client, and many providers issue a random identifier that means something only to the issuer, which resolves it through a token introspection endpoint. The shape is the quick test: a JWT is three base64url segments separated by dots and almost always begins with eyJ. If yours carries no dots there are no claims inside to read, and no decoder can invent them. Refresh tokens and opaque session tokens behave the same way by design — they are meant to be presented, not inspected.
Does decoding a JWT mean it is valid?
No, and the difference matters. The header and payload are base64url-encoded, not encrypted, so anyone holding a token can read them — that is why a JWT is never a place to put a secret. Only checking the signature against the right key tells you the token is genuine and unaltered, and that its claims can be trusted.
Which signature algorithms can it verify?
HS256, HS384 and HS512 with a shared secret, and RS256/384/512, PS256/384/512 and ES256/384/512 with a public key given as a PEM block, a single JWK, or a whole JWKS — in which case the token’s kid picks the key. Verification uses the browser’s built-in WebCrypto, so no key material is sent anywhere.
Is my signing key or secret stored?
No. Every other tool on this site saves your input to localStorage so a refresh does not lose your work; the verification key is deliberately excluded. It is held in memory, used for the check, and gone when you leave the page.
Why does my token show as expired?
The exp claim is a NumericDate — seconds since 1970 — and the decoder shows it as a real date alongside how long ago it passed. An expired token is the most common cause of a sudden 401 from an API that was working a moment earlier. A nbf claim in the future does the same thing at the other end.