JWT Decoder
Paste a JSON Web Token to see its header, payload and claims, with readable dates and an expiry check. Decoding happens in your browser and does not verify the signature.
Last updated
Encoded token
Summary
Decoded claims will appear here
Keyboard shortcuts:Ctrl ↵Copy payloadCtrl SDownload payloadCtrl KSearch tools
How to use the JWT Decoder
Paste your token
Paste a JWT into the input. A leading “Bearer ” copied from an Authorization header is removed automatically.
Read the summary
See the algorithm, issuer, subject, audience and a badge showing when the token expires.
Inspect the JSON
The header and payload are shown as formatted, syntax-highlighted JSON you can copy.
Verify on your server
Decoding doesn't check the signature — always verify it before trusting a token.
Features
- Decodes the header and payload into formatted, syntax-highlighted JSON
- Color-coded token structure showing the header, payload and signature
- Summary of standard claims (alg, typ, iss, sub, aud, exp, nbf, iat, jti) with readable local dates
- Expiry badge: “Expires in …”, “Expired … ago”, “Not valid until …” or “No expiry”
- Accepts tokens copied with a leading “Bearer ” prefix
- Detects encrypted tokens (JWE) and explains why they can't be decoded
- Copy the header or payload JSON, or open it in the JSON Formatter with one click
- Open exp, iat and nbf dates in the Timestamp Converter
- Download the header or payload as .json; Ctrl/Cmd + Enter copies the payload, Ctrl/Cmd + S downloads it
Is my token sent anywhere?
No. DevNest decodes the token in your browser with local Base64URL decoding and JSON.parse. The token isn't sent to a server or logged. If you open it from another tool or from search, it passes through this tab's session storage and is deleted as soon as the decoder opens. Even so, treat live tokens with care — see the security tips above.
Examples
Decode a token's payload
See the claims inside a token without needing its secret.
Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTc5MDAwMDAwMH0.signaturePayload
{ "sub": "user_42", "name": "Ada Lovelace", "role": "admin", "iat": 1790000000 }Spot an expired token
The exp claim is shown as a readable date with an Expired badge.
Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwiZXhwIjoxNjAwMDAwMDAwfQ.signatureExpiry
exp: 1600000000 = 2020-09-13T12:26:40.000Z → ExpiredPaste an Authorization header
A leading “Bearer ” is removed automatically, so you can paste the whole header value.
Header value
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTc5MDAwMDAwMH0.signatureResult
Decoded as normal — sub: "user_42", alg: HS256
Understanding JWTs
What is a JWT?
A JSON Web Token (JWT, defined in RFC 7519) is a compact, URL-safe way to pass claims between systems. JWTs are widely used as access tokens and ID tokens in OAuth 2.0 and OpenID Connect, and as session tokens in web apps. A JWT has three parts, each Base64URL-encoded and separated by dots:
HEADER.PAYLOAD.SIGNATUREHow a JWT works
- Header — JSON describing the token type and signing algorithm, for example
{"alg":"HS256","typ":"JWT"}. - Payload — JSON claims about the user or session, such as a user ID, the issuer and an expiry time, plus any custom data.
- Signature — calculated over the header and payload with a secret (HMAC) or a private key (RSA or ECDSA). It lets the receiver detect whether the token was changed.
The header and payload are only encoded, not encrypted: anyone who has the token can read them. That's why you should never put secrets in a JWT payload.
Common JWT claims
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Who created and signed the token |
| sub | Subject | Who the token is about — usually a user ID |
| aud | Audience | Who the token is intended for |
| exp | Expiration time | When the token expires (Unix seconds) |
| nbf | Not before | The token must not be accepted before this time |
| iat | Issued at | When the token was created |
| jti | JWT ID | A unique identifier, useful for preventing replay |
JWT decoding vs JWT verification
Decoding a JWT does not verify its signature or prove that the token is authentic.
Decoding simply reverses the Base64URL encoding — anyone can do it, and anyone can create a token containing any claims they like. Verification recalculates the signature with the correct secret or public key and checks that it matches, and also checks claims such as exp, nbf, iss and aud. Only a verified token should be trusted. DevNest only decodes; use a well-maintained JWT library on your server to verify tokens, and never accept tokens that use alg: none.
JWT security tips
- Treat tokens like passwords: a valid access token can be used by anyone who has it, until it expires.
- When debugging, prefer test tokens or tokens that have already expired.
- Don't paste production tokens into third-party websites unless you understand how they process your data.
- Never put passwords, API keys or other secrets in a JWT payload — it's readable by anyone.
Frequently asked questions
Can DevNest verify a JWT signature?
No. DevNest only decodes the header and payload, which doesn't require a key. Verify signatures on your server with a well-maintained JWT library and the correct secret or public key.
Why does the decoder say my token has expired?
The exp claim is compared with your device's clock at the moment you pasted the token. If your device clock is wrong, the status will be too. Servers often allow a small amount of clock skew as well.
Are JWTs encrypted?
Standard signed JWTs (JWS) are only encoded, so anyone can read the payload. Encrypted JWTs (JWE) have five parts instead of three and can't be read without the decryption key.
Why won't my token decode?
A JWT needs exactly three parts separated by dots, and the first two must be Base64URL-encoded JSON. Check that nothing was cut off when copying and that there are no surrounding quotes.
What does alg none mean?
It means the token has no signature. Servers must reject such tokens unless they are explicitly expected, because anyone could create or modify them.