JWT decoder, verifier and test-token builder
A JSON Web Token (RFC 7519) is three Base64URL-encoded parts joined by dots: header.payload.signature. This JWT decoder splits a token into its colour-coded parts, decodes the header and payload into formatted JSON, explains each claim in a table with human-readable dates, tells you whether the token has expired, and — if you supply the key — verifies the signature. An Encode tab lets you create signed test tokens for your own development work.
Example
The decoded header and payload of a typical access token:
{
"alg": "RS256",
"typ": "JWT",
"kid": "k1"
}
{
"sub": "42",
"name": "Ada",
"iat": 1767225600,
"exp": 1767229200,
"iss": "https://auth.example.com"
}Here iat is 2026-01-01 00:00:00 UTC and exp one hour later; the claims table shows those dates and whether the token is still valid right now.
What the fields mean
| Claim | Meaning |
|---|---|
alg | Signing algorithm, e.g. HS256 (HMAC-SHA256), RS256 (RSA), ES256 (ECDSA) or EdDSA |
kid | Key ID — which of the issuer’s keys signed the token |
iss / aud / sub | Issuer, intended audience and subject (usually a user ID) |
iat / nbf / exp | Issued-at, not-before and expiry times in Unix seconds |
For other timestamps, the Unix Timestamp Converter is handy.
Decoding is not verifying
The header and payload of a signed JWT (JWS) are only encoded, not encrypted, so anyone can read them — and anyone can edit them. Only the signature proves that the issuer created the token and that nobody changed it. That is why the verification step matters:
- HS256, HS384, HS512 use a shared secret: paste the same secret the server uses (as text, or Base64URL if your secret is stored that way).
- RS, PS, ES and EdDSA algorithms use a key pair: paste the issuer’s public key as a PEM, an X.509 certificate or a JWK — for example one entry from the issuer’s JWKS endpoint.
- Tokens with
"alg": "none"are flagged as unsigned; your application should reject them unless it explicitly expects unsigned tokens.
A successful check here is a debugging aid. Your application must still verify every token on every request with a maintained JWT library, and check the issuer, audience and expiry, not just the signature.
Creating test tokens
The Encode tab builds a token from a header and payload you edit as JSON and signs it with an HMAC secret (HS256, HS384 or HS512). It is useful for testing your own API locally or reproducing a bug. Use a long random secret — at least 32 bytes for HS256 — and never sign tokens for systems you do not control.
Common errors
- “A JWT must have three dot-separated parts”. The token was truncated or includes extra text. Copy it again from the Authorization header or cookie.
- “not valid Base64URL” / “not valid JSON”. A character was lost or changed while copying, often at a line break.
- Signature does not verify. Check that you used the right key (compare the kid), the full secret without extra spaces, and a public key in SPKI “PUBLIC KEY” PEM form rather than PKCS#1.
Privacy
Tokens, secrets and keys are processed in your browser and are not uploaded while you decode, verify or sign. Save & Share is different: on the Decode & verify tab the link stores the token itself on our server, and on the Encode tab it stores the header and payload. The secret or key is never included in the link. Treat live tokens like passwords anyway: a valid bearer token grants access until it expires, so prefer expired or test tokens when you share screenshots. Encrypted tokens (JWE, five parts) cannot be read without the recipient’s private key. To decode a single Base64URL part by hand, use Base64 Decode; to see how HS256 signatures are computed, try the HMAC Generator.