What the JWT tool does
A JSON Web Token (JWT) is a compact string that carries a set of claims — typically who a user is and what they are allowed to do — with a signature that lets the receiver check the token has not been tampered with. This tool decodes any JWT to show its header and payload as readable JSON, and can also build a new token from a payload and a secret using HS256. Decoding needs no secret, because the payload is only Base64-encoded, not encrypted. Everything runs in your browser; tokens you paste are not sent anywhere, which matters because a live token is a credential.
The three parts of a token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjM0IiwiZXhwIjoxNzUwMDAwMDAwfQ . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
header . payload . signature| Part | Contents | Encoding |
|---|---|---|
| Header | {"alg":"HS256","typ":"JWT"} — the signing algorithm | Base64URL of JSON |
| Payload | Claims: sub, exp, iat, roles, and anything else the issuer adds | Base64URL of JSON |
| Signature | HMAC or RSA/ECDSA signature over header.payload | Base64URL of raw bytes |
Base64URL is ordinary Base64 with + and / replaced by - and _ and no padding, so the token is safe in URLs and headers.
Standard claims
| Claim | Meaning | Notes |
|---|---|---|
| iss | Issuer | Who created the token |
| sub | Subject | Usually the user ID |
| aud | Audience | Which service the token is for |
| exp | Expiration | Unix timestamp; reject after this |
| nbf | Not before | Unix timestamp; reject before this |
| iat | Issued at | Unix timestamp |
| jti | JWT ID | Unique ID for revocation lists |
Timestamps are seconds since 1 January 1970 UTC. The decoder shows them as-is; 1750000000 is mid-June 2025. Any other keys (role, email, scope) are custom claims defined by the issuer.
Signing: HS256 vs RS256
- HS256 (HMAC-SHA256) — one shared secret both signs and verifies. Simple, fast, fine when the same service issues and checks tokens. Anyone with the secret can mint tokens, so it must never be shipped to a client.
- RS256 / ES256 (RSA / ECDSA) — a private key signs, a public key verifies. Used when many services verify tokens issued by one identity provider (Auth0, Cognito, Keycloak, Google). The public key is published at a JWKS URL.
This tool signs with HS256 only. Its encode mode is for building test tokens and understanding the format — use your framework's JWT library in production.
Security rules that are easy to get wrong
- Decoding is not verifying. Anyone can read a JWT's payload. Trust the claims only after the signature has been checked with the right key and the
expclaim is in the future. - Never put secrets in the payload. Passwords, card numbers and personal data are visible to anyone who sees the token. Use JWE (encrypted JWT) if confidentiality is required.
- Reject
alg: noneand never let the token dictate the algorithm — a classic attack swaps RS256 for HS256 and uses the public key as the HMAC secret. - Keep tokens short-lived (minutes to an hour) and use refresh tokens for longer sessions. A JWT cannot be revoked once issued unless you keep a deny-list.
- Use a strong secret for HS256 — at least 32 random bytes. Short secrets are brute-forced offline in seconds.
Common uses
- Inspecting the access token an app received to see which scopes or roles it actually carries.
- Debugging a 401 by checking whether
exphas passed orauddoes not match. - Building a test token with a known secret for a local API.
- Reading ID tokens from OpenID Connect to see the user profile claims.