JWT Decoder

A JSON Web Token (JWT, RFC 7519) is three base64url strings joined by dots: a header naming the signing algorithm, a payload of claims such as the user ID and expiry, and a signature. This decoder turns the first two back into readable JSON, lists each claim with its standard meaning, converts the iat, nbf and exp timestamps into dates, and says whether the token is inside its time window by your device clock. It is useful when an API returns 401, when you need to see which scopes or roles a token carries, or when you want to know exactly when a session expires.

1. Paste the token. A leading “Bearer ” from an Authorization header is removed for you.
2. Read the status: expired, not valid yet, within its time window, or no expiry.
3. Check the time claims, shown as dates in your time zone with the raw numbers beside them.
4. Switch between the claims table and raw JSON, and copy the header or payload.
5. Press “Try an example” to see a sample token if you don’t have one to hand.

• It does not verify the signature. Anyone can create a token with any claims, so a decoded payload proves nothing about who issued it. Verification needs the issuer’s secret or public key and belongs on your server.
• Encrypted tokens (JWE, five parts) can’t be read without the key; the decoder says so rather than showing garbage.
• The expiry status uses your device clock, which may be wrong. Servers also allow some clock skew.
• Nested or compressed payloads are shown as they are; the decoder doesn’t unwrap them.
• Decoding is plain base64url and JSON parsing in your browser. The token is never sent to SmartTools or anyone else, and it isn’t saved. Even so, a JWT is often a live credential: anyone who has it can act as you until it expires. Prefer test tokens, and never paste production tokens into any website — including this one.

The decoding happens entirely in your browser and nothing is transmitted, which you can confirm in your browser’s network tab. The bigger risk is the habit: a token copied into many sites can leak. Use expired or test tokens where you can.

Validity depends on the signature, and checking that needs the key the issuer signed with. A decoder that claimed a token was “valid” without the key would be misleading, so this one only reports what the token says about itself.

They are Unix timestamps in seconds. iat is when the token was issued, nbf is the earliest time it may be used, and exp is when it stops being accepted.

An alg of none means the token has no signature. Libraries have had vulnerabilities that accepted such tokens, so a server should always reject them.

Each part of a JWT is base64url-encoded JSON, so its contents are readable by anyone. A JWT adds a structure and a signature that lets a server detect tampering — it does not hide the data.