A JWT decoder splits a JSON Web Token into its three parts, base64URL-decodes the header and payload, and shows you the JSON claims inside — including expiry and issue times — without ever sending the token anywhere. Paste a token above and its header, payload, signature, and time claims appear instantly. Decoding happens entirely in your browser; the token is never verified server-side and never logged.
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe way to represent claims passed between two parties. It is the format behind most modern API authentication and single sign-on flows: after you log in, a server hands your client a signed token, and the client sends it back on each request to prove who it is. A JWT is a string with three sections separated by dots:
header.payload.signatureEach section before the dots is base64URL-encoded (a URL-safe variant of base64). Decoding is not decryption — the header and payload are merely encoded, not hidden, so anyone holding the token can read them. That is why you must never place a secret inside a JWT payload.
The three parts explained
- Header — a small JSON object describing the token, most importantly
alg(the signing algorithm, e.g. HS256 or RS256) andtyp(usuallyJWT). - Payload — the JSON object carrying the claims: who the token is about, when it expires, what it grants. This is the part you usually care about.
- Signature — a cryptographic value computed over the header and payload with a secret or private key. It lets a server confirm the token was not tampered with. This decoder shows the signature but does not verify it.
Standard time claims
The payload often contains registered claims defined by the JWT specification. The most useful are timestamps, stored as seconds since the Unix epoch:
| Claim | Meaning |
|---|---|
exp |
Expiration time — after this instant the token must be rejected. |
nbf |
Not before — the token is invalid until this instant. |
iat |
Issued at — when the token was created. |
sub |
Subject — the principal (often a user id) the token is about. |
iss / aud |
Issuer and audience — who minted the token and who it is intended for. |
The tool reads exp, iat and nbf automatically, converts them to readable dates, and flags whether the token is expired or not yet valid.
Why this tool does not verify signatures
Decoding and verifying are two different things. Decoding reveals what a token claims; verifying proves those claims are authentic and untampered. Verification requires the key that signed the token — the shared secret for HMAC algorithms like HS256, or the issuer’s public key for RSA and ECDSA algorithms like RS256 and ES256. That key never travels inside the token, so no decoder can check the signature on its own. Rather than pretend otherwise, this tool shows the signature raw and states plainly that it is unverified. Always verify tokens in your backend with the correct key before trusting them.
A worked example
Given the header {"alg":"HS256","typ":"JWT"} and a payload containing "exp":2053044800, the decoder base64URL-decodes both sections, pretty-prints the JSON, and converts the expiry to a calendar date. If that date is in the past, the status line reports the token as expired; if nbf is in the future, it warns the token is not yet valid. The signature segment is displayed but marked “not verified”.
A word on safety
Treat every JWT as a live credential. Although this page never transmits, logs, or stores what you paste — decoding runs on your device with the browser’s own base64 and JSON functions — you should never paste a production or session token into any online decoder you have not verified for yourself. A hostile page could quietly steal it. For sensitive tokens, decode them offline once this page has loaded, or use trusted local tooling. Our behaviour is inspectable so you can confirm exactly what happens to your input.