JWT Decoder
Share on Social Media:
JWT decoder: read the contents of any JSON Web Token instantly
A JWT decoder takes a JSON Web Token, that long dotted string your API hands out after login, and shows you the human-readable claims hidden inside. Paste the token and this online JWT decoder splits it into its three parts, Base64Url-decodes the header and payload, and prints clean JSON so you can see the issuer, expiry, subject, and any custom claims at a glance. It runs entirely in your browser, so the token never leaves your machine and there is no signup.
Tokens are everywhere in modern auth: OAuth 2.0, OpenID Connect, single sign-on, and stateless session cookies all lean on JWTs. When something breaks, like a 401 that should be a 200 or a session that expires too soon, the fastest fix is to decode the token and read it. A JWT decoder turns an opaque blob into the exact data your backend received.
How to use the JWT decoder
- Copy the token. Grab it from a response header (
Authorization: Bearer ...), a cookie, or your network tab. - Paste it in. Drop the full token into the input; the decoder splits it on the dots automatically.
- Read the header. See the signing algorithm (
alg) and key id (kid). - Read the payload. Inspect standard claims like
exp,iss, andsub, plus your app's custom claims. - Check the timestamps. Convert
expandiatfrom Unix seconds to confirm whether the token is expired.
How a JWT is structured
A JWT is three Base64Url-encoded segments joined by dots: header.payload.signature. The header and payload are JSON objects, merely encoded, not encrypted, which is why a decoder can read them with no secret. The signature is a cryptographic check that proves the token was not altered. A real token looks like eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw..., where each part before a dot decodes to readable content.
| Part | Contains | Encoded? | Example fields |
|---|---|---|---|
| Header | Token metadata | Base64Url, not encrypted | alg, typ, kid |
| Payload | Claims about the user | Base64Url, not encrypted | sub, exp, iss, roles |
| Signature | Integrity check | Binary, keyed hash | HMAC or RSA over header+payload |
The single most important point: a decoder reveals the payload but does not prove the token is valid. Anyone can read a JWT. Only your server, holding the secret or public key, can verify the signature. Never trust decoded claims for authorization without verifying the signature first.
Standard claims and what they mean
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who created and signed the token |
sub | Subject | The user or entity the token represents |
aud | Audience | The intended recipient API |
exp | Expiration | Unix time after which the token is invalid |
nbf | Not before | Unix time before which the token is invalid |
iat | Issued at | Unix time the token was created |
jti | JWT ID | Unique identifier to prevent replay |
The alg field in the header tells you how the token was signed. Common values are HS256 (HMAC with a shared secret), RS256 (RSA with a public/private key pair), and ES256 (elliptic curve). An alg of none is a red flag and should never be accepted by a production verifier.
Signing algorithms compared
Choosing between symmetric and asymmetric signing changes how you distribute keys. HMAC algorithms use one shared secret for both signing and verifying, which is simple but means every service that checks a token also holds the power to mint one. RSA and ECDSA split that into a private signing key and a public verification key, so you can publish the public key (often via a JWKS endpoint) and let many services verify without being able to forge tokens.
| Algorithm | Type | Keying | Good for |
|---|---|---|---|
HS256 | Symmetric (HMAC-SHA256) | One shared secret | Single service, simple setups |
RS256 | Asymmetric (RSA) | Private signs, public verifies | Multi-service, public verification |
ES256 | Asymmetric (ECDSA) | Smaller keys than RSA | Mobile, bandwidth-sensitive APIs |
PS256 | Asymmetric (RSA-PSS) | Private signs, public verifies | Stronger RSA padding scheme |
none | Unsigned | No key | Never in production |
Debugging auth problems with a decoder
Most token bugs fall into a few buckets, and decoding the token tells you which one you are in within seconds. The decode itself answers "what does the server actually see," which is usually different from what you assumed. Work through the claims in this order before you touch your code.
| Symptom | Claim to check | Likely cause |
|---|---|---|
| 401 on a valid login | aud, iss | Token issued for a different audience or issuer |
| Session expires too fast | exp minus iat | Token lifetime configured too short |
| "Token not yet valid" | nbf | Clock skew between issuer and verifier |
| Missing permissions | roles / scopes claim | Authorization server not adding the claim |
| Signature verification fails | kid, alg | Wrong key selected or algorithm mismatch |
A practical example: a user reports being logged out after a minute. Decode the token, read iat and exp, subtract them, and if the difference is 60 you have found your misconfigured lifetime without reading a line of backend code. Likewise, a 401 that "makes no sense" often comes down to an aud value pointing at the wrong API.
Common mistakes
- Treating the payload as private. JWT claims are only encoded, not encrypted, so never put passwords or secrets in a token.
- Trusting a decoded token without verifying. Decoding proves nothing about authenticity; always check the signature server-side.
- Misreading
exp. It is in Unix seconds, not milliseconds, so a value like1719230400is a date, not the year 1719. - Copying a partial token. Leaving off a segment or trailing characters yields a decode error; copy the whole dotted string.
- Accepting
alg: none. A token claiming no signature must be rejected by any secure backend.
Tips and related tools
When debugging auth, decode both the access token and the refresh token, and compare the exp values to understand the session lifecycle. Since payloads are JSON, you can pretty-print them with the JSON Formatter, confirm structure with the JSON Validator, explore nested claims in the JSON Viewer, or convert a claims set with JSON to XML for legacy systems. Find more developer utilities in the development tools hub.
Frequently asked questions
What is a JWT decoder? It is a tool that splits a JSON Web Token into its header, payload, and signature, then Base64Url-decodes the readable parts so you can inspect the claims as formatted JSON.
Is a JWT encrypted? No. The header and payload are only Base64Url-encoded, which means anyone can read them. Only the signature is cryptographic, and it proves integrity rather than hiding the contents.
Can a decoder verify the signature? Reading the token does not require a key, so a browser decoder shows the claims but cannot prove authenticity. Signature verification must happen on your server with the secret or public key.
How do I check if a JWT is expired? Read the exp claim, which is a Unix timestamp in seconds, and compare it to the current time. If the current time is greater, the token has expired.
Is it safe to paste my token here? Yes. This JWT decoder runs entirely in your browser and never uploads the token, though you should still avoid sharing production tokens publicly.
What does the alg field mean? It names the signing algorithm, such as HS256, RS256, or ES256. A value of none means the token is unsigned and should be rejected.
Why does my token fail to decode? The usual cause is a truncated or malformed token; make sure you copied all three dot-separated segments without extra spaces or line breaks.
Can I decode a token from a cookie? Yes. Copy the JWT value out of the cookie and paste it in; the decoder handles it the same way as a bearer token.
🔗 Relevant Tools
Link to this tool
Found this tool useful? Add it to your website or blog with one of these snippets.
Add the live, working tool to your own page:
Leave a comment
Comments go straight to our team — they are not published on the site.