Parses a JSON Web Token into header, payload and signature with claim explanations. Plus optional HMAC signature verification right in the browser — your secret never leaves the page.
JWT is a Base64url string of three parts separated by dots. Header — algorithm and type. Payload — a set of claims (data). Signature — signs header+payload with a secret. All three parts are Base64url without padding, readable by eye if you want.
Header and algorithms
alg
HS256, HS384, HS512 · RS256, ES256, none
HS* — symmetric, signed with a shared secret (HMAC-SHA). RS*/ES* — asymmetric, with a private key (RSA/ECDSA). alg: 'none' means unsigned — accept only for debugging, never in prod. Never trust the alg from the header during validation — pin the acceptable set.
Standard claims
RFC 7519
iss, sub, aud, exp, nbf, iat, jti
Reserved fields from the spec: iss (issuer), sub (subject), aud (audience), exp (expiration, Unix), nbf (not before), iat (issued at), jti (unique id). Your app can add any custom claims (name, email, roles). Names are usually short to keep the token small.
Do and don't
Security
no: password · yes: id, roles, expiry
JWT doesn't encrypt, only signs — anyone can read the payload. Never put passwords, card numbers, PII. Do put user id, roles, expiry. Keep the secret server-side only. On compromise — short lifetime (exp) + refresh mechanism.
05
Frequently asked questions
Paste the token and it splits into its three parts, with the header and the payload shown as formatted JSON. Registered claims get plain-language labels and every timestamp is rendered as a readable date, so you can see at a glance when the token was issued, when it expires and how long is left.
No. The decoding runs entirely in your browser, and the token is neither uploaded nor stored. The same goes for the secret you may enter to check the signature — it stays on the page. This is not a detail: a live token is live access to an account, so pasting one into a server-side service hands that access away.
No. A standard JWT is signed, not encrypted: the payload is base64url text that anyone can read without a key, as this page demonstrates. That is why passwords, document numbers and similar data do not belong in a token. The signature proves the token was not altered; it does nothing to hide what is inside.
It is the expiry time as a Unix timestamp — seconds since 1 January 1970 UTC. The tool shows it as an ordinary date and says whether the token has expired and by how much. You will usually see `iat` next to it, the moment of issue, and sometimes `nbf`, the moment before which the token must be rejected.
For tokens signed with HS256, HS384 or HS512, enter the secret in the verification section and the signature is recomputed in your browser. A match means the token has not been altered since it was issued. RS* and ES* tokens cannot be checked here — those need the issuer's public key, which belongs on the receiving server.
A header naming the signing algorithm, a payload carrying the claims, and the signature, joined by dots. The first two are base64url-encoded JSON; the third is a cryptographic operation over them and a key. That is why every token has exactly two dots and why the parts carry no trailing padding characters.