JWT Decoder
Paste a JSON Web Token to read its header and claims, see when it expires, and check its signature with a secret or public key. The token is decoded in your browser and never uploaded.
What is a JWT?
A JWT (JSON Web Token) is a compact token that apps use to prove who you are, most often after you sign in. It is three base64url parts joined by dots: a header that names the signing algorithm, a payload of claims such as your user ID and when the token expires, and a signature.
The server signs the token with a secret or private key. Later, any service that has the secret or the matching public key can check the signature and trust the claims without looking anything up. The format is defined in RFC 7519.
Why use our JWT decoder
- ·Your token stays private. Decoding and signature checks run in your browser. Nothing is sent to a server.
- ·Claims in plain words. Each claim is named, and timestamps are shown as dates with how long ago or how soon they are.
- ·Real signature checks. HMAC, RSA, RSA-PSS, ECDSA, and EdDSA, with PEM, JWK, or a full JWKS.
- ·Clear error messages. Tells you what is wrong with a broken token or key, and how to fix it.
- ·Free. No signup, no paywall, no limits.
How to decode and verify a JWT
- 1
Paste your token
Copy the JWT from your app, a request header, or your browser's developer tools and paste it into the box. A leading 'Bearer ' is removed for you. The header, payload, and claims appear right away.
- 2
Read the claims
The payload shows the token's claims as formatted JSON. The table under it names each standard claim and turns times like exp and iat into readable dates, with how long ago or how soon they are.
- 3
Check whether it has expired
The status line shows whether the token is expired, not valid yet, or still active, based on its exp and nbf claims and your device's clock.
- 4
Verify the signature
Enter the secret for HS256, HS384, or HS512 tokens, or paste the public key (PEM, JWK, or a JWKS key set) for RS, PS, ES, or EdDSA tokens. The tool tells you whether the signature matches.
JWT claims explained
These seven registered claims are defined by the JWT standard. All of them are optional, and a token can add any custom claims it needs, such as a name, email, or role.
| Claim | Name | What it means |
|---|---|---|
| iss | Issuer | Who created and signed the token, usually a URL. |
| sub | Subject | Who the token is about, usually a user ID. |
| aud | Audience | Which app or API the token is meant for. |
| exp | Expiration time | When the token stops being valid. |
| nbf | Not before | When the token starts being valid. |
| iat | Issued at | When the token was created. |
| jti | JWT ID | A unique ID for this token, used to block reuse. |
The time claims (exp, nbf, and iat) are whole seconds since 1 January 1970 UTC, not milliseconds.
Decoding a JWT does not prove it is genuine
Anyone can write a token with any claims they like, base64url encode it, and paste it here. It will decode just fine. What makes a real token trustworthy is the signature, which only the holder of the secret or private key can produce. That is why this tool says "Signature not checked" until you give it a key.
The same goes the other way: the payload is readable by anyone who has the token. Signing stops people from changing it, not from reading it. Keep passwords, API keys, and personal data you would not want exposed out of JWT payloads.
Why is my JWT rejected?
When an API answers 401 Unauthorized, decode the token here and check these common causes:
- ·The token has expired. If the status says Expired, the exp time has passed and servers will reject it. Get a new token by signing in again or by using your app's refresh token. Access tokens often last only minutes to an hour.
- ·The server's clock is off. A token that looks valid here can fail on a server whose clock is a few minutes ahead or behind, especially right after it was issued (nbf) or just before it expires. Most JWT libraries let you allow a small clock skew.
- ·The secret is in the wrong form. Some systems store the HMAC secret as base64. If the signature fails with a secret you know is right, turn on 'Secret is base64 encoded' and try again.
- ·The wrong public key. Identity providers rotate keys. The kid in the token header names the key that signed it. Paste the whole key set (JWKS) and the tool picks the key with the matching kid.
- ·The token was cut off or changed. A token copied from a log or a wrapped line may be missing characters, which breaks the signature or the decoding. Copy it again from the original source.
- ·The audience or issuer does not match. Servers also check that aud names their API and iss names the expected issuer. Compare those claims with your server's settings if the signature passes but requests still fail.
Frequently asked questions
- How do I decode a JWT?
- Paste the token into the box at the top of this page. The header and payload are decoded right away and shown as formatted JSON, with a table that explains each claim and turns timestamps into dates. You do not need the secret or key to decode a token, only to verify it.
- Is it safe to paste my JWT into this decoder?
- Yes. The token is decoded and checked entirely in your browser and is never sent to a server. That matters because a valid token works like a password for as long as it lasts. Even so, avoid pasting live production tokens into any website you do not trust.
- Can anyone read the data inside a JWT?
- Yes. A normal signed JWT is only encoded with base64url, not encrypted, so anyone who has the token can read its header and payload. Never put passwords or other secrets in a JWT payload. Encrypted tokens (JWE) have five parts instead of three and cannot be read without the key.
- What is the difference between decoding and verifying a JWT?
- Decoding just reads the header and payload. Verifying checks the signature with the secret or public key, which proves the token came from the issuer and has not been changed. A decoded token can be fake. Only trust its claims after the signature is verified.
- How do I verify a JWT signature?
- Look at the alg value in the header. For HS256, HS384, or HS512, enter the shared secret. For RS, PS, ES, or EdDSA algorithms, paste the issuer's public key as a PEM block, a JWK, or a JWKS key set. The tool shows Signature verified or Invalid signature.
- Where do I find the public key for my identity provider?
- Most providers publish their keys as a JWKS file. Look for jwks_uri in the provider's OpenID configuration at /.well-known/openid-configuration on the issuer URL, open that address, and paste the whole JSON into the public key box.
- What time format do exp and iat use?
- They are a number of seconds since 1 January 1970 (UTC), also called a Unix timestamp. For example, 1767225600 is 1 January 2026 at midnight UTC. Note that JavaScript dates use milliseconds, so a common bug is setting exp 1000 times too large.
- What does alg: none mean?
- It means the token has no signature, so anyone could have written it. Servers should always reject these tokens. Some old JWT libraries accepted them by mistake, which let attackers make fake tokens.
- Which algorithms can this tool verify?
- HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, and EdDSA (Ed25519). EdDSA needs a recent browser. Keys in the older PKCS#1 format and X.509 certificates need to be converted to a standard public key first, and the tool tells you how.