JWT mistakes we see in real APIs
JSON Web Tokens are easy to adopt and easy to get wrong. These are the common JWT mistakes in APIs, why they matter, and how to fix each one properly.
Free tool
JWT Decoder, Encoder & Verifier
Decode, verify and create JSON Web Tokens with any signing algorithm. Check a signature with your key, flag risky settings, and generate or convert keys.
Runs entirely in your browser. Nothing you enter is sent to us.
Use test tokens and test keys. Everything runs in your browser and nothing is sent anywhere, but a live token is a credential and a production private key should never leave your systems.
An "Authorization: Bearer" prefix, quotes and line breaks are removed automatically.
Verify the signature (optional)
For a JWK Set, the key matching the token's kid is used. A private key works too: its public half is used.
Findings
No risky settings found in the header or payload.
Token
header · payload · signature
Header
Payload
Encrypted PEM files need decrypting first.
Unsigned tokens have no signature. Use them only to check that your server rejects them.
Signed token
Verify with this public key
Findings
No risky settings found.
Generate a key
Or convert a key
Converts between PEM and JWK, works out the public key from a private one, and calculates the RFC 7638 thumbprint for use as a kid.
Key
How to use the result
Reading the result
Signature verified means the token was signed by the key you supplied and hasn't been changed since. It doesn't mean the token is still valid: check the expiry and the findings too.
Critical or high findings: treat them as vulnerabilities. A server that accepts alg: none lets anyone forge tokens. A short or well-known HMAC secret can be cracked offline from a single token. Secrets or personal data in a payload are readable by anyone who holds the token.
Medium: review your design. Tokens without an expiry, or that carry their own key (jwk) or a key URL (jku, x5u), are only safe if the server ignores those values or checks them against an allow-list.
Low and info: context to check, such as long lifetimes, clock problems or how a kid is looked up.
The tool checks tokens and keys. Whether your API actually rejects a forged, tampered or expired token can only be shown by testing the server, which is part of an API penetration test.
Background
What a JWT is
A JSON Web Token (JWT) is a compact way to pass claims between systems, such as who a user is and when their session ends. It has three parts separated by dots: a header that names the signing algorithm, a payload of claims, and a signature.
The header and payload are only Base64URL-encoded, so anyone who holds the token can read them. The signature stops the token being changed, but only if the server checks it properly with the right key and an algorithm it expects.
Supported algorithms
- HMAC: HS256, HS384, HS512, with secrets as text, Base64 or hex.
- RSA: RS256, RS384, RS512 (PKCS#1 v1.5) and PS256, PS384, PS512 (RSA-PSS), with 2048 to 4096-bit keys.
- ECDSA: ES256 (P-256), ES384 (P-384), ES512 (P-521) and ES256K (secp256k1).
- EdDSA: EdDSA with Ed25519 or Ed448, and the newer fully specified Ed25519 and Ed448 identifiers from RFC 9864.
- Unsigned:
none, for checking that servers reject it.
Supported key formats
PEM private keys (PKCS#8, PKCS#1 RSA PRIVATE KEY, SEC1 EC PRIVATE KEY), PEM public keys (SPKI and PKCS#1), X.509 certificates, single JWKs and JWK Sets. The Keys tab converts between them and calculates RFC 7638 thumbprints for key IDs.
What the checks look for
- Algorithm problems:
alg: none, a missing algorithm, and HMAC secrets that are too short or well known. - Keys in the header:
jwk,jkuandx5uvalues that a server might wrongly trust, andkidvalues worth checking. - Lifetime and timing: no expiry, an invalid expiry, very long lifetimes, and clock problems with
nbfandiat. - Sensitive claims: fields that look like passwords, secrets or personal data.
What a tool can't tell you
Whether your API rejects a token with alg: none, a changed signature, a key it shouldn't trust or an expired exp can only be found by sending those tokens to the server. That's one of the things an API penetration test checks.
FAQ
JWT Decoder & Encoder questions
Is it safe to paste a real token or key here?
The tool runs entirely in your browser and sends nothing anywhere: decoding, signing, verifying and key generation all happen on your device. A live token is still a credential and a production private key should never leave your systems, so use test tokens and test keys, and never paste either into tools that send them to a server.
Which algorithms can it sign and verify?
Every registered JWS signing algorithm: HS256, HS384 and HS512; RS256, RS384 and RS512; PS256, PS384 and PS512; ES256, ES384, ES512 and ES256K; EdDSA with Ed25519 or Ed448, plus the Ed25519 and Ed448 identifiers from RFC 9864. It can also create unsigned (alg none) tokens for testing that servers reject them.
What key formats does it accept?
PEM private keys in PKCS#8, PKCS#1 (RSA PRIVATE KEY) and SEC1 (EC PRIVATE KEY) formats, PEM public keys, X.509 certificates, single JWKs and JWK Sets. HMAC secrets can be text, Base64 or hex. The Keys tab converts between formats and calculates RFC 7638 thumbprints for key IDs.
How do I verify a token from my identity provider?
Paste the token, then paste the provider's public key into the verify box. A whole JWK Set (the JSON published at the provider's jwks_uri) works: the key matching the token's kid is picked automatically. Download the JWK Set yourself; the tool never fetches anything.
Is a JWT encrypted?
A standard signed JWT is not. Its payload can be read by anyone who holds the token. Encrypted tokens (JWE) exist, and the tool shows their readable header, but most APIs use signed tokens, so keep secrets and personal data out of the payload.
How long should an access token last?
As short as your application can tolerate, usually minutes rather than days, with a refresh token to get a new one. A short lifetime limits the damage if a token leaks.
Related
API Penetration Testing
Hands-on testing of REST, GraphQL and gRPC APIs for broken authorization, data exposure and abuse of business logic.