JWT Decoder
Paste a JSON Web Token to read what is inside it. Claims such as expiry are translated into readable dates, and you can check the signature with a secret or public key.
- Runs in your browser
- No sign-up
- Free to use
| Claim | Meaning | Value |
|---|
How to use JWT Decoder
- Paste the token into the input box. It is decoded immediately.
- Read the header and payload, and check the claims table for expiry, issue time and audience.
- To verify the signature, enter the shared secret for HS algorithms or paste the PEM public key for RS and ES algorithms.
- Copy the decoded header or payload if you need it elsewhere.
JWT Decoder features
Client-side only
The token is decoded in your browser and is never transmitted, logged or stored.
Readable claims
exp, iat and nbf timestamps are shown as dates with a clear expired or valid status.
Signature verification
Supports HS256/384/512, RS256/384/512 and ES256/384/512.
Helpful error messages
Explains whether the token has the wrong number of parts or a segment is not valid Base64URL or JSON.
Algorithm warnings
Flags unsigned tokens that use alg “none”.
When to use JWT Decoder
- Debugging a 401 response by checking whether an access token has expired.
- Confirming which scopes, roles or audience a token carries.
- Verifying that a token was signed with the key you expect.
- Understanding the structure of tokens issued by an identity provider.
JWT Decoder FAQ
Is it safe to paste a real token here?
The token is processed only in your browser and no request is made with it. Even so, treat production tokens like passwords: prefer test tokens, and never paste tokens on a device you do not trust.
Can anyone read the contents of a JWT?
Yes. The header and payload are only Base64URL-encoded, not encrypted. Anyone holding the token can read the claims. The signature prevents tampering; it does not hide data. Never put secrets in a JWT payload.
What do exp, iat and nbf mean?
They are Unix timestamps in seconds. exp is when the token expires, iat when it was issued and nbf the time before which it must not be accepted.
Why does verification fail with the right secret?
Check that the secret is entered exactly, including whether it is Base64-encoded, and that the token has not been altered or re-wrapped. For RS and ES tokens you need the public key that pairs with the signing key, in PEM format.
Does decoding prove the token is valid?
No. Decoding only shows the contents. A token should be trusted only after its signature, expiry, issuer and audience have all been validated by your application.
How a JSON Web Token is put together
A JWT is three Base64URL-encoded segments separated by dots. The first is the header, a small JSON object naming the signing algorithm and token type. The second is the payload, a JSON object of claims: statements about the user and the token itself. The third is the signature, computed over the first two segments with a secret or private key.
The receiver recomputes or checks the signature to confirm that the header and payload have not been changed since the token was issued. With HS algorithms the same secret signs and verifies. With RS and ES algorithms the issuer signs with a private key and anyone can verify with the corresponding public key, which is why they suit systems with many verifying services.
Because the payload is readable by anyone, JWTs are appropriate for identifiers and permissions, not for confidential data. Short expiry times limit the damage if a token leaks.