JWT Decoder
Updated Free mock REST & WebSocket APIs
Paste a JSON Web Token to read its header and claims. Timestamps are converted to readable dates and you'll see at a glance whether the token has expired. Decoding runs in your browser — the token is never sent anywhere.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzg0MTIiLCJuYW1lIjoiQW5hIFJpdmVyYSIsImVtYWlsIjoiYW5hQGV4YW1wbGUuY29tIiwicm9sZSI6ImFkbWluIiwiaXNzIjoiaHR0cHM6Ly9hdXRoLmV4YW1wbGUuY29tIiwiYXVkIjoibW9ja2ZveC1hcGkiLCJpYXQiOjE3NjAwMDAwMDAsIm5iZiI6MTc2MDAwMDAwMCwiZXhwIjoyMDUxMjIyNDAwfQ.3cvNh7lqJ1yF0d3vK8bQ2mWnH4sXtA9pRzE6uYgLk0o
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "user_8412",
"name": "Ana Rivera",
"email": "ana@example.com",
"role": "admin",
"iss": "https://auth.example.com",
"aud": "mockfox-api",
"iat": 1760000000,
"nbf": 1760000000,
"exp": 2051222400
}Signature not verified. Decoding only reads the token — anyone can create a token with any claims. Your server must verify the HS256 signature with the secret or public key before trusting it.
🔒 Decoded entirely in your browser — the token is never sent anywhere, logged or stored.
How to decode a JWT
- Paste the token — with or without the “Bearer ” prefix.
- Check the badge and the exp, iat and nbf dates to see whether it's currently valid.
- Read the header (alg, kid) and payload claims, and copy either one as formatted JSON.
How a JWT is structured
A JWT is three Base64URL strings joined by dots: header.payload.signature. The header names the signing algorithm (alg) and often a key ID (kid). The payload holds the claims. The signature is computed over the first two parts with a secret or private key. The header and payload are only encoded, not encrypted — anyone holding the token can read them, so never put secrets in claims.
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who created the token (e.g. your auth server URL) |
sub | Subject | Who it's about — usually the user ID |
aud | Audience | Which API the token is meant for |
exp | Expiration | Seconds since 1970 after which it must be rejected |
nbf | Not before | Seconds since 1970 before which it must be rejected |
iat | Issued at | When the token was created |
jti | JWT ID | Unique ID, used to prevent replay or revoke a token |
Decoding is not verifying
Anyone can build a token with any claims; only the signature proves it came from your issuer and wasn't changed. On the server, verify with a maintained library, pin the expected algorithm (never accept alg: none or let the token choose between HMAC and RSA), check exp and nbf with a small clock-skew allowance of 30–60 seconds, and validate iss and aud.
Related tools
Frequently asked questions
Is it safe to paste a production token here?
The token is decoded locally and never transmitted, logged or stored. Still treat live tokens like passwords: anyone who has one can use it until it expires, so don't share them in screenshots or chat.
Why does it say the signature isn't verified?
Verifying needs the issuer's secret or public key, and checking a signature in a web page would encourage pasting secrets. Decoding only shows what the token claims; your backend must verify it.
Can it decode encrypted tokens (JWE)?
No. An encrypted JWT has five parts and its payload can only be read with the decryption key. The tool detects this and tells you.
What time zone are exp and iat in?
They're NumericDate values — seconds since 1970-01-01 UTC — so they have no time zone. The tool shows them in your local time and as ISO 8601 UTC.
Your business here? Sponsor this tool from $16/week. See placements