About this tool
A JSON Web Token has three Base64URL-encoded parts separated by dots: header, payload, and signature. This tool decodes the first two — which is safe to do without any secret key, since a JWT's payload is signed, not encrypted — and shows you the algorithm, every claim, and whether the token has expired. Decoding runs entirely in your browser.
How to use the JWT Decoder
- Paste a JWT into the box — the full string including both dots.
- Read the header and payload, pretty-printed as JSON.
- Check the expiry status at a glance if the token has an
expclaim.
Common use cases
- Debugging why an API call is being rejected — checking if a token has actually expired
- Inspecting what claims (user ID, roles, scopes) a token actually carries
- Verifying an auth service is issuing tokens with the algorithm and claims you expect
Header vs. payload vs. signature
The header typically contains just the signing algorithm (like HS256 or RS256) and token type. The payload holds the actual claims — registered ones like sub (subject/user ID), iat (issued at), and exp (expiry), plus whatever custom claims the issuing service added, like roles or permissions. The signature is what proves the token wasn't tampered with — it's a cryptographic hash of the header and payload, generated with a secret (or private key) that only the issuing server should know. This tool intentionally doesn't touch the signature, since verifying it would require that secret, which should never be entered into a third-party site.
Things to watch out for
Anyone can decode a JWT's payload — it's not encrypted, just encoded, so never put sensitive data like passwords directly in the claims. A decoded token that "looks valid" tells you nothing about whether its signature actually checks out; a tampered token will still decode and display fine here, since decoding and verifying are separate steps. Treat any real JWT with the same care as a password or API key — decoding it locally in a browser tool is fine, but avoid pasting production tokens into any website you don't trust.
Decoding a JWT by hand
A signed JWT in compact form is three Base64URL strings joined by dots. Base64URL is the URL-safe variant of Base64 defined in RFC 4648: it uses - and _ instead of + and /, and JWTs leave off the trailing = padding. To decode a part yourself, swap those two characters back, add = until the length is a multiple of 4, then Base64-decode it. For example, the very common header eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 decodes to {"alg":"HS256","typ":"JWT"}. This tool does exactly that for the first two parts, then decodes the bytes as UTF-8 so non-English characters in claims display correctly.
The registered claims
RFC 7519 defines seven registered claim names. None is mandatory, but most tokens use several:
iss(issuer): who created the token, often the auth server's URL.sub(subject): who the token is about, usually a user ID.aud(audience): who the token is intended for. An API should reject tokens meant for a different audience.exp(expiration),nbf(not before) andiat(issued at): times in seconds since 1970-01-01 UTC. For example,1798761600is 2027-01-01 00:00:00 UTC.jti(JWT ID): a unique ID, which servers can use to stop a token being replayed.
Other claims, such as roles or email, are defined by whoever issued the token.
What the "Valid" badge means
The expiry status here compares exp with your device's clock and nothing else. It does not check nbf, the audience or the signature. A token can show "Valid" and still be rejected by the server if the signature doesn't match, the token isn't active yet, or your computer's clock is wrong. Because the values are in seconds, not milliseconds, an exp that looks thirteen digits long was probably written in milliseconds by mistake. The Timestamp Converter turns these values into readable dates.
Watch for alg "none"
RFC 7518 defines "alg": "none" for unsecured tokens, which have an empty signature. If a decoded header shows none, the token proves nothing about who made it. RFC 8725, the JWT best-practices document, says libraries should only accept the algorithms an application expects.
Frequently asked questions
No. This tool only decodes the header and payload, which is safe to do without the secret key since a JWT's payload isn't encrypted, only signed. Verifying a signature requires the secret key or public key, which should never be pasted into a third-party website.
Decoding happens entirely in your browser using JavaScript's built-in Base64URL handling — the token is never sent to a server. That said, treat any JWT like a password once decoded elsewhere: don't paste tokens from sensitive production systems into any tool, including this one, unless you've reviewed what it does.
These are registered time claims: iat is when the token was issued, exp is when it expires, and nbf ("not before") is the earliest time the token becomes valid. All three are Unix timestamps.
Yes. The header and payload of a signed JWT are only Base64URL-encoded, not encrypted, so anyone holding the token can read them. The secret or public key is needed only to verify the signature. Encrypted JWTs (JWE) are different: their five-part payload cannot be read without the key.
exp is a NumericDate: the number of seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds. For example, 1798761600 means January 1, 2027 at midnight UTC. A value with thirteen digits is usually milliseconds by mistake, which would put expiry tens of thousands of years in the future.