JWT Tool (Decode / Verify / Sign)
Decode JWTs, verify signatures, and sign new tokens with strict controls. Your token stays in your browser — no uploads.
About this JWT tool
JWTs are everywhere: browser sessions, API calls, and mobile logins. A JSON Web Token (JWS) is three Base64URL segments—header, payload, and signature. Decoding the first two parts is easy, but trusting them without verification is a common security mistake. This tool lets you paste a token and inspect the header and claims with clear formatting, copy buttons, and an “expires in” countdown for exp/nbf/iat. You can also re-encode edited JSON back to Base64URL to see exactly what changes (without silently “fixing” the signature).
Verification runs client-side using the WebCrypto API. In Strict mode, the verifier rejects alg=none, requires an allowed-algorithm list, and prevents key/algorithm confusion (for example, using an RSA key to verify HS256). Provide a shared secret, a PEM public key, a JWK, or a JWKS (paste or fetch from a URL) and see which key matched by kid. For token creation, sign HS*, RS/PS, or ES tokens for reproducible test fixtures—without uploading secrets.
Use cases
Inspect header.alg/typ and payload claims (iss, sub, aud, exp, nbf, iat, jti) without executing anything. Great for quickly understanding what a token contains.
Validate HS/RS/PS/ES signatures locally. Strict mode rejects alg=none, enforces an allowed-algorithms list, and blocks key/alg confusion.
Paste a JWK or JWKS (or fetch it from a JWKS URL) and let the tool select the right key via kid. Override manually when debugging key rotation.
See human-readable times and countdowns for exp/nbf/iat. Add leeway to account for small clock differences between clients and servers.
Edit header/payload JSON and re-encode segments to compare changes. Signing is separate, so you can clearly see why the signature becomes invalid.
Everything runs in your browser. No uploads, no token logging. If you choose JWKS URL, the request is made directly from your device.
Search intents we cover
These are common queries and scenarios people run into when decoding, verifying, and signing JWTs.
JWT FAQ
Is JWT encryption?
No. A JWT (JWS) is usually a signed token. Anyone can Base64URL-decode the header and payload; the signature is what provides integrity.
What is JWS vs JWE?
JWS is a signed JWT with 3 parts. JWE is an encrypted JWT with 5 parts; you need the right key to decrypt its contents.
What does alg=none mean, and why is it risky?
alg=none disables signature verification. Accepting it can let attackers forge tokens. Strict mode rejects alg=none.
HS vs RS: what’s the difference?
HS* uses a shared secret (HMAC). RS*/PS* use asymmetric RSA keys (public key verifies, private key signs). They are not interchangeable.
What is kid and how does JWKS help?
kid identifies which key was used. A JWKS is a set of keys; the verifier picks the matching key by kid (or you can override manually).
Why does my token say “expired” or “not active yet”?
Check exp and nbf (plus iat). This tool shows an “expires in” countdown and supports leeway for clock skew.
What is clock skew (leeway)?
Servers and devices can be a few seconds off. Leeway lets you accept small time differences when validating exp/nbf/iat.
Can I trust decoded payload without verifying?
No. Decoding is just Base64URL. Always verify the signature and validate claims before trusting the data.
Why does re-encoding break the signature?
The signature is computed over header.payload. If you change either part, the signature must be recalculated with the right key.
Does this tool upload my token?
No. Decode/verify/sign runs locally in your browser. Only JWKS URL fetch (if enabled) makes a request to that URL from your device.