What a JWT actually is
A JSON Web Token is three chunks of base64url text joined by dots. The first chunk is the header, which names the signing algorithm. The second is the payload, a JSON object of claims such as who the token belongs to and when it expires. The third is the signature, computed by the issuing server over the first two chunks.
Because base64url is an encoding rather than encryption, the header and payload are readable by anyone who holds the token. That is by design: a JWT is meant to be inspected. What keeps it honest is the signature, which only a party holding the right secret or private key can produce. This page decodes the readable parts entirely in your browser, so the tokens you paste are never uploaded, logged or stored anywhere.
Worked examples
The time claims are the ones people decode tokens to check. All three registered time claims (exp for expiry, iat for issued-at, nbf for not-before) are plain Unix timestamps in seconds, which is why a 10-digit number appears where you expected a date. The tool converts each one to a readable date and compares exp and nbf against your device clock to show whether the token is expired, not yet valid, or still inside its window.
Decoding is not verifying
This is the trap that catches people. Anyone can mint a token that claims to be from anyone, about anyone, with any role and any expiry. It will decode perfectly here and everywhere else. The only thing that separates a genuine token from a forged one is the signature, and checking a signature requires the issuing server's secret (for HMAC algorithms like HS256) or its public key (for RS256 and friends), which a static page in your browser does not and should not have.
So use a decoder for what it is good at: reading claims while debugging, checking why a request started returning 401 (an expired exp, nine times out of ten), confirming which algorithm and key ID a token was issued with, and seeing exactly what your identity provider is putting inside access tokens. Never use decoded output as evidence that a token is genuine, and never build client-side logic that trusts claims without the server having verified the signature first.
Practical token hygiene
Treat a live token like a password, because until it expires that is what it is. Prefer short expiry times with refresh tokens over long-lived access tokens, and avoid putting anything secret in the payload, since everyone who handles the token can read it. If you have pasted a production token into chat logs, issue trackers or a colleague's screen share while debugging, rotate it. And if a token refuses to decode at all, check the usual suspects: it may be truncated by a clipboard or log line, it may be a five-section encrypted JWE rather than a signed JWT, or it may be an opaque session ID that was never a JWT in the first place.
Frequently asked questions
Is my token uploaded anywhere?
No. The token is decoded with JavaScript in your browser and never leaves your device. That makes it safe to inspect real tokens from live systems, although it is still good practice to rotate any credential you have been pasting around while debugging.
Does this tool verify the signature?
No, and this matters. It only decodes what the token says about itself. Anyone can create a token with any payload they like, so a decoded claim proves nothing until a server checks the signature against the correct secret or public key.
What are exp, iat and nbf?
They are registered time claims, each a Unix timestamp in seconds. The exp claim is when the token expires, iat is when it was issued, and nbf is the moment before which it must not be accepted. This tool converts all three to readable dates and compares exp against your device clock.
Why does my token fail to decode?
A JWT must be three base64url sections separated by dots, with the first two containing JSON. Extra whitespace and a leading Bearer prefix are handled for you, but truncated tokens, five-section encrypted JWEs and opaque session identifiers that merely look like tokens will all fail.
Can anyone read a JWT?
Yes. Base64url is an encoding, not encryption, so anyone who holds the token can read the header and payload in full. Never put passwords, card numbers or other secrets in a JWT payload, and treat the token itself as a credential to be kept private.