Free JWT Decoder — Inspect JSON Web Tokens
Paste a JWT to see its header and payload, with timestamps translated to readable dates. Decoding happens locally — your token never leaves the browser.
⚠️ The signature is not verified — decoding only proves what the token says, not that it's authentic. Verification requires the signing secret or public key on a server.
The three parts of a JWT, and what each one is for
Every JWT is three Base64URL-encoded sections joined by dots: header.payload.signature. The header names the signing algorithm and token type; the payload carries the actual claims — who the token represents, when it was issued, when it expires; the signature is a cryptographic proof, computed from the header and payload using a secret or private key, that lets a server confirm the first two sections haven't been tampered with since they were signed. Base64URL is a small variant of standard Base64 — it swaps + and / for - and _ and usually drops the trailing = padding — specifically so the encoded token is safe to place directly in a URL or HTTP header without further escaping.
Why JWTs trade off against traditional session cookies
A traditional session ID is an opaque reference — the server looks it up in a session store on every request to find out who's making it, which also means a compromised session can be instantly revoked by deleting that entry. A JWT is self-contained: the server can verify a request's identity just by checking the signature, with no database lookup required, which scales better across multiple servers. The cost is exactly the flexibility a session store provides — a JWT issued with a long expiry generally can't be revoked before it naturally expires without extra infrastructure (a blocklist, short expiries plus refresh tokens) layered on top.
Frequently Asked Questions
Is it safe to paste a real token here?
Decoding runs entirely in your browser — the token is never transmitted or logged. That said, treat production tokens like passwords: prefer expired or development tokens when debugging, since anyone who obtains a live token can use it.
Why can I read a JWT without the secret key?
JWTs are encoded (Base64URL), not encrypted. The secret key only creates the signature that proves the token wasn't tampered with — it doesn't hide the contents. Never put sensitive data in a JWT payload.
What are exp, iat, and nbf?
Standard time claims, as Unix timestamps: exp is when the token expires, iat when it was issued, and nbf ("not before") the earliest moment it's valid. This tool converts each to a readable date and tells you if the token is expired.
Why does my token fail to decode?
A JWT must be three Base64URL sections separated by dots. Common issues: extra whitespace or line breaks from copying, a truncated token, or an opaque session ID that isn't a JWT at all.
How is a JWT different from a traditional session cookie?
A session cookie is just an opaque reference the server looks up in a session store to identify who's making a request — which also means it can be instantly revoked by deleting that entry. A JWT carries its own signed claims, so a server can verify it without a database lookup, but that same self-contained design usually means it can't be revoked early without extra infrastructure on top.
What do the "iss," "aud," and "sub" claims mean?
They're standard registered claim names: "iss" (issuer) identifies who created the token, "aud" (audience) identifies who it's intended for, and "sub" (subject) identifies the user or entity the token represents — commonly a user ID.