⏳
How to handle JWT expiration and token refresh
Why JWTs expire, what the exp claim really is, and how the access-token + refresh-token pattern keeps users logged in without long-lived credentials.
· 8min read Read more ->
JWT Decoder
Decode and inspect a JWT's header, payload and claims online. Runs 100% in your browser - your tokens are never uploaded or sent to any server.
Your files never leave your browser. Nothing is uploaded to any server. Privacy Policy
Paste any JSON Web Token to instantly decode the header and payload, view standard claims (iss, sub, exp, iat) in human-readable form, and check expiry status. Decoding runs entirely in your browser - your tokens never leave your device.
How to decode a JWT
1
Paste the token
Copy your JWT (the long string with two dots) into the input.
2
Inspect parts
Header and payload are decoded automatically as you paste.
3
Check claims
Standard claims like exp and iat are highlighted with their meaning.
Header & payload
Both segments are Base64URL-decoded and pretty-printed as JSON.
Claim formatting
Timestamps (iat, exp, nbf) are converted to readable dates and validity status.
Expiry check
See immediately whether a token is currently valid, expired or not yet active.
Local only
Decoding happens in your browser - tokens are not transmitted anywhere.
The anatomy of a JSON Web Token
A JSON Web Token (JWT) is three Base64URL-encoded strings joined by dots: header.payload.signature. The first two segments are plain JSON that anyone can read once decoded - only the signature requires a secret to produce or verify.
- Header - describes the token: the signing algorithm (
alg, e.g.HS256orRS256) and type (typ: "JWT"). - Payload - the claims: who the token is about, who issued it, when it expires, and any custom data your app added.
- Signature - a cryptographic hash of the header and payload, created with a secret (HMAC) or private key (RSA/ECDSA). It proves the token wasn't tampered with.
Because the header and payload are only encoded - not encrypted - never put passwords or secrets inside a JWT. Anyone who intercepts it can read every claim, exactly as this decoder does.
Standard JWT claims explained
The JWT spec (RFC 7519) reserves seven registered claims. Your backend usually adds custom claims (like role or email) alongside them.
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who created and signed the token. |
sub | Subject | Who the token is about - usually the user ID. |
aud | Audience | The recipient the token is intended for. |
exp | Expiration | When the token stops being valid, as a Unix timestamp. |
nbf | Not before | The token is invalid until this time. |
iat | Issued at | When the token was created. |
jti | JWT ID | A unique identifier, used to prevent replay. |
The decoder above converts exp, iat and nbf from Unix seconds into readable UTC dates automatically and tells you whether the token is currently valid.
Decoding vs. verifying a JWT
These are two different operations, and mixing them up is the most common JWT mistake.
- Decoding reads the header and payload. It needs no key - anyone holding the token can do it, including this tool. Decoding tells you what a token claims, not whether those claims are true.
- Verifying recomputes the signature using the issuer's secret or public key and checks it matches. Only verification proves a token is authentic and untampered, and it must happen on your backend, where the key is kept - never in the browser.
So this decoder is a debugging and inspection tool: use it to see why a token was rejected, check an exp time, or confirm which claims your auth provider sends. Never treat a decoded payload as trusted input in your application.
Why decode JWTs in your browser instead of a server-side tool
A JWT is often a live credential - an access or session token that grants whoever holds it. Pasting one into a typical online decoder sends that credential to a stranger's server, where it can be logged, cached, or replayed until it expires.
Filesty decodes entirely in your browser with JavaScript. The token is split and Base64URL-decoded locally; no network request is made and nothing is stored. You can verify this yourself: open your browser's DevTools -> Network tab, paste a token, and watch - not a single request fires.
For a token that is still valid, that difference matters. Decode it here, or in your own terminal, rather than handing an active credential to a third party.
Common JWT errors and what they mean
- "Not a valid JWT" - the string doesn't have the required parts. A JWT is
header.payload.signature(orheader.payloadfor an unsigned token). Check for a missing dot or copied whitespace. - "Invalid header / payload" - a segment isn't valid Base64URL-encoded JSON. This usually means the token was truncated, or a
Bearerprefix was pasted along with it. - Token expired - the
expclaim is in the past. The token decoded fine; it's simply no longer accepted, and your app needs to refresh it. - Signature "can't be verified here" - expected. Verification needs the signing key and belongs on your server; this tool only decodes.
FAQ
Paste the token into the box above. Filesty splits it on the dots and Base64URL-decodes the header and payload instantly, right in your browser. Nothing is uploaded to a server.
No - verifying a signature requires the secret or public key. This tool only decodes the readable parts (header and payload).
No. Anyone can decode a JWT to read its claims. Verification checks the signature with the signing key and must be done by your backend.
Yes. Decoding only reads the Base64URL-encoded header and payload, which need no key. The secret is only required to create or verify the signature, not to read the claims.
No. JWT decoding is pure Base64URL decoding - it runs locally in your browser and makes no network request, so your token is never uploaded.
Only if the decoding happens locally. Many online tools send your token to their server. Filesty decodes in your browser with no network request, so an active token is never exposed. Even so, avoid pasting production credentials into any tool you don't trust.
JWS is the standard that defines how a JWT's header and payload are signed so their integrity can be verified. A signed JWT is technically a JWS. This tool shows the signature segment but does not verify it.
A JWT has three parts separated by dots: header (algorithm and type), payload (claims) and signature. The header and payload are Base64URL-encoded JSON.
iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued-at), nbf (not-before), and jti (token ID).