JWT Decoder
Paste a JWT. See its header, claims and dates, and check the signature with your key. Nothing leaves your browser.
- 0
- Claims
- 0
- Issues
- 0
- Errors
On this page
About JWT Decoder
Updated
What is a JWT Decoder?
A JWT Decoder reads a JSON Web Token and shows what is inside: the algorithm in the header and the claims in the payload. This one also shows every time as a date and says if the token has expired or is not valid yet. It checks the signature with the key you give it. It decodes and verifies in your browser, so a live token never leaves your computer.
How to use this tool
Paste the token in the Token tab. The token can have Bearer or the whole Authorization: line in front of it, quotes around it, or line breaks inside it. The tool reads the token anyway, and Clean token removes the rest. The Result pane opens on Claims. It shows each claim, its value, the date for times such as exp, and what the claim means. Payload and Header show the decoded JSON for copying. Timeline shows when the token is valid, and Tree shows a big payload key by key.
To check the signature, open the Key tab and paste the key. For HS256, HS384 and HS512 that is the shared secret. For RS, PS, ES and EdDSA tokens it is the issuer's public key: a PEM block, an X.509 certificate, a JWK, or the whole JWKS from the issuer. With a JWKS, the tool picks the key by its kid. The tool never loads a key from a URL.
What the colours mean
The tool marks the exact character where a broken token fails, and gives the reason and the fix. A token that decodes can still be wrong. A red note means that a server rejects the token: it has expired, or the signature does not match the key. An amber note means a risk: no exp, alg: none, a short secret, or nbf in the future.
Customization
Open Options to show times in your local time or in UTC, and to say whether an HMAC secret is plain text or Base64URL. The tool remembers your choices.
Common JWT errors
Bearer and quotes copied with the token
Tokens are often copied from a request header or a JSON response, with more than the token. A library expects the bare token:
Bearer eyJhbGciOiJIUzI1NiJ9.e30.XmNK3GpH3Ys_7wsYBfq4C3M6goz71I7dTgUkuIa5lyQRemove the word Bearer and the space, or press Clean token:
eyJhbGciOiJIUzI1NiJ9.e30.XmNK3GpH3Ys_7wsYBfq4C3M6goz71I7dTgUkuIa5lyQBase64 instead of Base64URL
JWT parts are Base64URL: - and _ take the place of + and /, and there is no = padding. Strict libraries such as jose reject a token that has + or /. Lenient libraries such as PyJWT accept it. So the same token can work in one service and fail in the next. Many libraries accept = padding, but the standard leaves it out:
eyJzdWIiOiI/Pz8ifQ==Encode with a Base64URL function, or replace the characters and drop the padding:
eyJzdWIiOiI_Pz8ifQTimes in milliseconds
exp, nbf and iat are seconds since 1 January 1970 UTC. JavaScript's Date.now() gives milliseconds, so a token made with it expires after the year 68,000:
{
"sub": "user_8231",
"exp": 2108458800000
}Divide by 1000 and round down: Math.floor(Date.now() / 1000) + 3600 for one hour.
{
"sub": "user_8231",
"exp": 2108458800
}Accepting alg none
A token with alg: none has no signature, so anyone can write one with any claims. A server that trusts the header's algorithm accepts it:
{
"alg": "none",
"typ": "JWT"
}Sign every token, and let the server choose the algorithms it accepts, never the token:
{
"alg": "RS256",
"typ": "JWT",
"kid": "2026-10"
}JSON Web Tokens
A JSON Web Token is a short, URL-safe string that carries claims between two parties, defined in RFC 7519. Many sign-in systems use it. An OpenID Connect ID token tells an app who the user is. An OAuth 2.0 access token can be a JWT too, and it says what an app may do.
The three parts
A signed JWT has three parts joined by dots: header.payload.signature. Each part is Base64URL-encoded. The header is JSON that names the algorithm (alg) and often the key (kid). The payload is JSON with the claims. If you write a payload yourself, check it in the JSON Validator before you sign it. The signature is made over the first two parts, so a change to either one breaks it. An encrypted JWT (JWE, RFC 7516) has five parts, and only its header can be read without the key.
Registered claims
iss: the issuer, who made the token.sub: the subject, the user or app the token is about.aud: the audience, who the token is for.exp: the expiry time; after it the token must be rejected.nbf: not before; the token must be rejected before this time.iat: issued at, when the token was made.jti: a unique ID, used to stop a token being used twice.
Signing algorithms
HS256, HS384 and HS512 use one shared secret to sign and to verify. So every service that checks the token can also make one. HS256 is HMAC with SHA-256. HMAC is a keyed hash: it mixes the secret into the hash of the first two parts. A plain SHA-256 hash, such as the one from the Hash Generator, has no key, so it does not give the signature. RS256 and PS256 (RSA), ES256 (ECDSA) and EdDSA sign with a private key. They verify with a public key, which the issuer publishes as a JWKS. Use a public-key algorithm when tokens cross a trust boundary. For HS256, use a secret of at least 32 random bytes (RFC 7518).
Decoding is not trusting
Anyone can read a JWT and anyone can make one. Do not put secrets in the payload, and never act on a token you have only decoded. A server verifies the signature with a known key and a fixed list of algorithms, then checks exp, nbf, iss and aud, as RFC 8725 describes.
Other JWT resources
- RFC 7519: JSON Web TokenThe JWT standard: the compact format and the registered claims iss, sub, aud, exp, nbf, iat and jti.
- RFC 7515: JSON Web SignatureHow a JWT is signed, the header parameters, and Base64URL encoding.
- RFC 8725: JWT Best Current PracticesHow to use JWTs safely: algorithm checks, key length, audience and issuer checks.
- OpenID Connect Core: Standard ClaimsThe user claims in ID tokens, such as name, email and email_verified.
- Microsoft Entra access token claimsWhat tid, oid, scp, roles and the other Microsoft claims mean.
- OWASP JSON Web Token Cheat SheetThreats to JWTs, such as unsecured tokens, key type confusion and audience confusion, and how to stop them.
- joseThe JavaScript library this tool uses to verify signatures with the browser's Web Crypto API.
JWT Decoder FAQ
What is a JWT decoder?
A JWT decoder turns the first two of the three Base64URL parts of a JSON Web Token back into readable JSON. The header names the algorithm, and the payload holds the claims. The third part is the signature, which is binary data. This one also shows the times as dates, says when the token expires, and checks the signature when you give it the key.
How do I decode a JWT token?
Paste the token in the Token tab. It decodes as you type. The Claims view lists every claim with its meaning, Payload and Header show the JSON, and Timeline shows when the token is valid.
To do it by hand, split the token at the dots, change - to + and _ to /, and Base64-decode the first two parts. In a browser console: JSON.parse(atob(token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/'))). That shows non-ASCII text, such as ë, as wrong characters. This tool decodes it correctly.
Can I decode a JWT without the secret key?
Yes. The header and payload of a signed JWT are only encoded, not encrypted, so anyone who has the token can read them. The secret or public key is needed only to check the signature, that is, to prove that nobody changed the token. An encrypted token (JWE, five parts) is different: to read its payload, you need the receiver's private key, or a key or password that both sides share.
Is it safe to paste my JWT into a decoder?
Only if the decoder runs in your browser. A JWT is a password for as long as it is valid: anyone who copies it can act as you. This tool decodes and verifies in your browser. The token and the key are never sent to a server, and nothing is put in the URL.
Even so, prefer test tokens, and do not paste a live production token or a private key anywhere you do not control.
Can I decode a JWT locally or offline?
Yes. When this page has loaded, decoding needs no network. The page loads the signature check after your first decode. After that, you can go offline and still decode and verify tokens. In code, libraries such as jose (JavaScript), PyJWT (Python) and golang-jwt (Go) decode and verify tokens on your own machine.
What is the difference between decoding and verifying a JWT?
Decoding reads the header and payload. Verifying checks the signature with the key, and checks that the token is not expired and is meant for you. A server must always verify. Decoding alone proves nothing, because anyone can make a token with any payload. Paste the key in the Key tab to verify here.
Why does my JWT signature not match?
These are the usual causes:
- The key is wrong.
- The secret is stored as Base64, but you pasted it as text. Set Options: Secret to Base64URL.
- The token changed or was cut short when you copied it.
- The issuer rotated its keys, and you have the old public key. For an RS256 token, take the key whose
kidmatches the token from the issuer's JWKS. It is often at/.well-known/jwks.json.
Is JWT obsolete?
No. JWTs are the standard format for OpenID Connect ID tokens and for many OAuth 2.0 access tokens (RFC 9068), and every major identity provider issues them. What is out of favour is using long-lived JWTs as browser sessions without a way to revoke them. Keep tokens short-lived, and follow the JWT best practices in RFC 8725.
Where do I find my JWT?
In the browser, press F12 to open DevTools and go to the Network tab. Select a request to the API and find the Authorization header. The token comes after the word Bearer.
If there is no such header, look in the Application tab (Storage in Firefox), under Cookies, Local storage and Session storage. You can also find the token in the response to the login or token request, as access_token or id_token.