$ jwt --decode
JWT Decoder Online — Decode and Validate JWT Tokens
Paste a token to decode header and payload in real time, understand each claim and, if you want, validate the signature — all without the token leaving your browser.
- 100% in your browser
- free
- no sign-up
Decoding happens in real time, as you type or paste.
Paste a token above or click “Generate an example token” to see the header, payload and claims explained.
How to use the jwt decoder
Paste the token into the field above and decoding happens instantly: the header shows the signing algorithm (alg) and the token type, the payload brings the claims, and the table explains each one. Temporal claims like exp, iat and nbf are converted from Unix seconds to a readable local date, with a live countdown — you immediately see whether the token expires in 12 minutes or is already expired. If you do not have a token at hand, click “Generate sample token” to create an HS256 JWT signed right in the browser.
To go beyond decoding a jwt, use the signature verification section: with the secret (HS256) or the public key in PEM or JWK (RS256/ES256), the tool validates the token with Web Crypto and explains the result — including the classic case of a valid signature on an expired token.
Decoding is not validating
This is the most common confusion with JWT. The token contents are just Base64Url — an encoding format, not encryption — so any online jwt decode reveals the payload without any key. What protects the token is the signature: without validating it, there is no guarantee the contents were not forged or tampered with. In practice, the backend must always validate the signature, expiration (exp), issuer (iss) and audience (aud) before trusting any claim. Use this page to inspect and debug; leave the trust decision to the server.
Another important caution: never paste production tokens into sites you do not know — a valid token is an access credential. Here that risk does not exist because nothing is transmitted: decoding and verification run locally, and you can confirm in the browser's network tab that no request leaves the page.
Everyday use cases
- Debug a 401/403 error: check whether the token is expired, whether the
audmatches the API and whether the expectedscope/rolesare present. - Integrate OAuth 2.0 / OpenID Connect: inspect the access token and the ID token issued by Keycloak, Auth0, Cognito, Azure AD or Firebase and understand claims like
azpandkid. - Validate your own implementation: generate a token in your application and check here whether the signature matches the expected secret or public key.
- Study authentication: the sample token lets you see in practice the header.payload.signature anatomy of a JWT.
## faq
Frequently asked questions
Is decoding a JWT the same as validating the token?
No. Decoding is merely converting the Base64Url of the header and payload into readable JSON — anyone can do it without any key. Validating is verifying the cryptographic signature with the secret (HS256) or the public key (RS256/ES256) and checking claims like exp and aud. A token can be perfectly readable and still be invalid or forged.
Is it safe to paste my JWT into this tool?
Yes: decoding and signature verification run 100% in your browser, with JavaScript and Web Crypto — nothing is sent to servers. Even so, the good practice applies to any site: avoid pasting production tokens into tools you do not know, because a valid token grants access to whatever it authorizes. Prefer expired tokens or ones from test environments.
Why can I read the JWT contents without having the key?
Because a JWT is signed, not encrypted. Header and payload are just JSON encoded in Base64Url, a reversible transport format. The key only comes into play in the signature, which guarantees integrity and authenticity — not confidentiality. That is why you should never store passwords, card numbers or any sensitive data inside a JWT payload.
What is the difference between HS256 and RS256?
HS256 is symmetric: the same secret signs and verifies the token, so whoever verifies can also issue. RS256 is asymmetric: the private key signs and the public key only verifies, which lets you distribute verification to several APIs without exposing the ability to issue tokens. ES256 follows the same asymmetric logic, using elliptic curves with smaller keys.
What does the exp claim mean and why does my token show as expired?
The exp (expiration time) claim stores the instant, in Unix seconds, from which the token is no longer accepted. If that instant has passed, the token is expired and servers must reject it, even with a valid signature. Access tokens usually last from minutes to a few hours — renewal is done with a refresh token, not by extending exp.
Can I verify the signature of any JWT here?
The tool verifies the most common algorithms: HS256/384/512 with the typed secret, and RS256/384/512, PS256/384/512 and ES256/384/512 with the public key in PEM (SPKI) or JWK. Tokens with unusual algorithms, or JWE (encrypted tokens), are not supported — in those cases the tool still decodes the header so you can identify the algorithm.
## other tools