JWT Decoder
A client-side JWT decoder. Paste a JSON Web Token and instantly see the decoded header and payload, with the standard claims (iss, sub, aud, exp, iat, nbf) explained and the expiry shown as a live countdown. Everything runs in your browser — the token is never sent anywhere, so it is safe to paste a real one.
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}Registered claims
sub1234567890Subject — who or what the token is about.iat1516239022 → Jan 18, 2018, 7:00:22 AMIssued-at — when the token was created.
A JWT looks cryptic, but two-thirds of it is just JSON you can read. The token is three base64url segments separated by dots — header.payload.signature — and only the signature is opaque. Decode the first two and you have plain JSON: the header tells you the algorithm, the payload carries the claims.
The claims are where the meaning lives. iss, sub and aud answer who issued the token, who it represents, and who it is meant for. The time claims are Unix timestamps: iat when it was minted, nbf the earliest it is valid, and exp when it dies. A server checks that the current time sits between nbf and exp and that the signature holds — and this tool shows you exactly those values so you can see why a request was accepted or a 401 came back.
The one thing to internalise: encoded is not encrypted. Anyone holding a JWT can read its payload, so never put secrets in it, and always verify the signature server-side before trusting a single claim. This decoder deliberately stops at reading — it never asks for your key — and it runs entirely in your browser, so pasting a live token here doesn’t leak it.
How it works
- Splits header.payload.signature and base64url-decodes each part.
- Explains the standard claims: iss, sub, aud, exp, iat, nbf.
- Shows a live expiry countdown and valid / expired state.
- Runs 100% in your browser — the token is never sent anywhere.
Frequently asked questions
What is a JWT made of?
A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm (e.g. HS256, RS256) and token type. The payload holds the claims — statements about the subject, such as who issued it (iss), who it is about (sub), who it is for (aud), and when it expires (exp). The signature is a MAC or digital signature over the first two parts, used to verify the token was not altered. The first two parts are only encoded, not encrypted, so anyone can read them.
Is it safe to paste a real token here?
Yes. This decoder runs entirely in your browser with JavaScript — the token is never transmitted to any server, logged, or stored. That said, a JWT is a credential: if it is unexpired, someone who has the token can often use it. Treat it like a password, and prefer a decoder like this one that works offline over any tool that sends the token to a remote server to decode it.
Can this tool verify the signature?
No — and that is intentional. Verifying a signature requires the secret (for HMAC) or the issuer’s public key (for RSA/ECDSA), and safely handling secrets in a web page is a bad idea. This tool decodes and inspects the token so you can read its claims and check expiry during development and debugging. Actual verification must happen server-side with the correct key; never trust a JWT’s contents in your app without verifying its signature first.
What do exp, iat and nbf mean?
They are standard time claims, expressed as Unix timestamps (seconds since 1970-01-01 UTC). exp (expiration) is the moment after which the token must be rejected. iat (issued-at) is when it was created. nbf (not-before) is the earliest time it may be accepted. This tool converts each to a readable local time and shows whether the token is currently valid, already expired, or not yet active — the three states a server would enforce.