Quick answer
A JWT (JSON Web Token) has three Base64URL parts separated by dots: the header (algorithm), the payload (data such as the user ID and the exp expiry) and the signature. The header and payload are only encoded, NOT encrypted, so anyone holding the token can read them; the signature is what proves the token has not been tampered with.
What is a JWT?
Paste a token to see its header and payload as readable JSON, a table explaining each standard claim (iss, sub, aud, exp, iat…), the issue and expiry times, and whether the token is still valid. Signature verification uses your browser's WebCrypto for HS256/384/512 (enter the secret) and RS, PS and ES algorithms (enter a PEM or JWK public key). The token is never sent to any server.
How to decode and verify a JWT
- 1
Paste the token into the JWT box. A whole “Bearer eyJ…” line from an Authorization header is fine; the Bearer prefix and whitespace are stripped.
- 2
Read the header (alg, typ, kid) and the payload. The Claims table explains each field and converts iat, nbf and exp to readable dates.
- 3
The expiry status line tells you how long until the token expires, whether it already has, or whether it is not valid yet.
- 4
To be sure the token is untouched, enter the secret (for HS256…) or the public key (for RS256, ES256…) under Verify signature.
Registered claims (RFC 7519)
| Claim | Full name | Meaning |
|---|---|---|
| iss | Issuer | Who issued the token, e.g. https://accounts.google.com |
| sub | Subject | Who the token is about, usually the user ID |
| aud | Audience | Which app or API may accept the token |
| exp | Expiration time | Expiry (Unix seconds); reject the token after this |
| nbf | Not before | Do not accept the token before this time |
| iat | Issued at | When the token was issued |
| jti | JWT ID | A unique ID for the token, used to prevent replay |
JWT times are SECONDS since 1 Jan 1970 UTC, not milliseconds like JavaScript's Date.now().
Common signing algorithms
| alg | Key type | Who can verify | Notes |
|---|---|---|---|
| HS256 / HS384 / HS512 | One shared secret | Only whoever holds the secret | Simple; fits one system that both issues and checks tokens |
| RS256 / RS384 / RS512 | RSA key pair | Anyone with the public key | The most common choice in OAuth and OpenID Connect |
| PS256 / PS384 / PS512 | RSA key pair (RSA-PSS) | Anyone with the public key | A theoretically stronger RSA variant |
| ES256 / ES384 / ES512 | Elliptic-curve key pair | Anyone with the public key | Short, fast signatures; used by Apple and Google |
| none | None | Nobody | An unsigned token; servers must reject it |
Swipe sideways to see the whole table →
Real-world examples
An API call returns 401
Paste the token you are sending: if the status says “Expired 2 hours ago”, the app needs to refresh the token rather than change how it calls the API.
Check a user's permissions
Many systems put roles in the payload, such as "role": "admin" or "scope": "read write". Decode it to confirm the token carries the right permissions before debugging elsewhere.
Verify a Google, Auth0 or Keycloak token
OpenID Connect providers sign with RS256 and publish their public keys as JWKs at the jwks_uri. Take the key whose kid matches the header and paste it into the public key box.
Experiment while coding
Click “Use a sample token” (the jwt.io example, secret “your-256-bit-secret”) to see a valid token, then change one character of the payload to watch the signature fail.
Common problems and fixes
- Putting passwords or card numbers in the payload because the token looks encrypted.
- The payload is just Base64URL; anyone can decode it, as you can see here. Keep secrets out of JWTs, or use JWE when the content must be confidential.
- “A JWT must have exactly 3 parts”.
- The token was cut off when copying or has extra characters. Copy the whole line again; a 5-part token is an encrypted JWE.
- The signature fails even with the right secret.
- Many libraries store the secret Base64-encoded: tick “Secret is Base64 encoded”. A trailing space in the secret also breaks it.
- The public key format is rejected.
- Use a PEM starting with -----BEGIN PUBLIC KEY----- or a JWK in JSON. Certificates and PKCS#1 keys (BEGIN RSA PUBLIC KEY) must be converted to SPKI with openssl first.
- A freshly issued token is already expired.
- exp is in seconds. exp = Date.now() + 3600 (milliseconds) is wrong; use Math.floor(Date.now() / 1000) + 3600. A server clock that is off causes the same symptom.
- The server accepts alg “none”.
- That is a serious vulnerability: attackers can mint unsigned tokens. Configure your library to accept only the algorithm you actually use.
Decoding is not verifying
Decoding simply turns Base64URL back into JSON; it needs no key and proves nothing. Verifying recomputes the signature over the header and payload with the key and compares it with the third part: if they match, the token really was signed by the key holder and not a single character has changed.
Servers must always verify the signature and expiry before trusting anything in a token. Front-end code may decode a token to show the user's name, but must never grant access based on it.
A word on pasting tokens
Everything on this page runs in your browser with WebCrypto; tokens, secrets and keys are not sent anywhere. Still, prefer test tokens, expired tokens or development tokens. A live session token works like a key: whoever gets it can use that session.
Glossary
- JWT
- JSON Web Token: signed JSON data used for sign-in and API authorisation.
- JWS / JWE
- A JWS is signed (the content is readable); a JWE is encrypted (unreadable without the key).
- Claim
- A name–value pair in the payload, such as sub, exp or role.
- Base64URL
- A Base64 variant using - and _ instead of + and /, without trailing =, safe inside URLs.
- JWK / JWKS
- A key written as JSON; a JWKS is the list of public keys a provider publishes for verifying tokens.
- kid
- Key ID in the header, telling you which JWKS key signed the token.
Frequently asked questions
Do I need the secret to decode a JWT?
No. Anyone can read the header and payload. The secret or public key is only needed to verify the signature.
Is my token sent anywhere?
No. Decoding and verification run in your browser; no network request contains the token.
Why does the signature fail?
The token was modified, the secret or key is wrong, the secret needs Base64 mode, or the public key does not match the kid in the header.
Can it decode a 5-part JWE?
No. A JWE is genuinely encrypted and needs the issuer's decryption key.
Which time zone are the dates in?
The raw values are Unix seconds in UTC. The tool shows Vietnam time (UTC+7) alongside the ISO form in UTC so you can compare.
Should I use HS256 or RS256?
HS256 when one system both issues and checks tokens. RS256 or ES256 when several services must verify tokens without holding the signing key, since they only need the public key.
Ratings and comments
Loading…