Decode any JSON Web Token, lint its claims, see its lifetime on a timeline, verify HS/RS/PS/ES/EdDSA signatures with a secret, PEM, JWK or JWKS, mint signed test tokens with generated keys, and decrypt JWEs — the token and your keys never leave the page.
Decode a token to see the checks.
Decode a token above to verify its signature.
Most JWT sites decode. This page decodes, then does the things you actually need next: it reads the claims the way a strict verifier would, shows the lifetime on a timeline, checks the signature with whatever key material you have, mints tokens with freshly generated keys for tests, and opens encrypted tokens.
Expired or not-yet-valid, lifetime too long, timestamps in milliseconds, alg: none, a key or key URL carried in the header, missing typ, kid, iss, aud or jti, sensitive-looking claim names, and cookie-size limits — each with the reason it matters. Enter the issuer and audience you expect and mismatches are flagged too.
HS256/384/512 with a secret (raw or base64url), RS and PS with a PEM public key in SPKI or PKCS#1 form, ES256/384/512 and EdDSA with PEM or JWK, and a whole JWKS document from which the token's kid selects the key — the way a real resource server does it.
Pick any of the thirteen algorithms, generate a key pair in the browser, and get the private key, public key, JWK and a ready JWKS document. The signed token loads straight into the inspector and verifies against the public half, so you have a complete fixture for an integration test in seconds.
Decrypt five-part tokens using dir, AES key wrap, RSA-OAEP, PBES2 password-based keys or ECDH-ES, with AES-GCM or AES-CBC-HMAC content encryption. Encrypt a test payload the same way to see what your consumers will receive.
Click a template to load it. The last two are there to show what the claims check catches.
JWTs often contain personal data or authorization scopes, and the keys used to verify or sign them are the most sensitive material a service has. Sending either to a remote server for processing is a transfer you may not be allowed to make. All decoding, verification, signing and decryption here runs in your browser with the Web Crypto API, and the indicator in the header counts network requests the page makes so you can see it stays at zero.
HS256, HS384 and HS512 with a shared secret; RS256, RS384 and RS512 and the RSA-PSS variants PS256, PS384 and PS512 with an RSA key; ES256, ES384 and ES512 with P-256, P-384 and P-521 keys; and EdDSA with Ed25519. Keys can be pasted as PEM (SPKI or PKCS#1 public keys, PKCS#8 private keys), as a single JWK, or as a JWKS document, in which case the token's kid header selects the key. Certificates and legacy PKCS#1 private keys are recognised and the message tells you the openssl command to convert them.
It applies the rules a strict verifier would: the algorithm must be a signed one, the header must not carry its own key or key URL, exp must exist and be in the future, nbf must be in the past, iat must not be in the future beyond clock skew, timestamps must be seconds rather than milliseconds, the lifetime should be short, iss and aud should be present and, if you enter the expected values, must match, long-lived tokens should carry a jti, claim names that look like secrets are flagged, and the token should fit in a cookie. Each finding explains why it matters.
Paste the whole JWKS document, the JSON with a keys array that your identity provider publishes at its jwks_uri. The token's kid header is matched against the kid of each key; if the token has no kid, the first key is used. The selected JWK is imported for the token's algorithm and the signature is checked. This mirrors what a resource server does, so a token that verifies here will verify there with the same document.
They are generated by your browser's Web Crypto implementation with proper random number generation, so cryptographically they are sound. The practical answer is still no: keys for production belong in a key management system or hardware module with access controls and rotation, not in a browser tab. Use the generated pairs for local development, test fixtures and understanding the formats.
A JWS, the common three-part token, is signed: anyone can read the payload, and the signature proves who issued it and that it was not altered. A JWE has five parts and is encrypted: only the holder of the recipient key can read the payload. JWE headers name two algorithms, alg for how the content key is protected and enc for how the content itself is encrypted. A signed token can be nested inside an encrypted one when both authenticity and confidentiality are required.
JWTs are stateless and self-contained. Traditional cookies require the backend to perform a database lookup for every request to verify session data. JWTs store the session data directly in the payload, which is cryptographically signed. This allows API gateways and microservices to verify authorization instantly without hitting a central session database, significantly improving scalability — at the cost of revocation being harder, which is why lifetimes should be short.
Decoding a JWT requires no key and no permission — the header and payload are Base64url, which is an encoding rather than a lock. That means two things at once: this tool can show you every claim in any token you hold, and so can anybody else who gets hold of it. A JWT payload is a postcard, not an envelope.
Verification is the separate operation that actually matters. It recomputes the signature with a key you supply and proves the token was issued by the holder of that key and has not been altered since. This tool does both, and keeps them visibly distinct, because conflating them is the root of most JWT vulnerabilities. Our guide on decoding versus verifying covers the failure modes in detail.
alg: noneRFC 7518 defines an algorithm meaning "unsigned". A verifier that reads the algorithm from the token and honours "none" accepts any payload at all. Verifiers must use an explicit allowlist of algorithms and never accept unsigned tokens.
A verifier configured for RSA that lets the token's header switch it to HMAC will treat the public key as a shared secret. The fix is the same: pin the algorithm in the verifier's configuration, not the token.
exp, nbf and iat are seconds since the epoch. Date.now() returns milliseconds. Multiply by a thousand too many and your tokens never expire — a silent hole nobody notices until the claims check points at it.
A valid signature is the first check, not the only one. Before a request reaches your business logic, all of the following should hold:
jwk, jku or x5u.algorithms: ['RS256'] rather than letting the library infer it.iss equal to your expected issuer, compared exactly.aud including this specific service, so a token minted for another service cannot be replayed here.exp in the future and nbf in the past, with 30–60 seconds of clock leeway.sub resolving to a principal that still exists and is still permitted.typ: at+jwt for access tokens.The first two defeat forgery. The middle ones defeat misuse of genuine tokens. The last defeats replay of tokens that were legitimate once. Skipping any tier leaves a whole category of attack open, which is why "we check the signature" is a beginning rather than an answer. The claims check above walks exactly this list.
Signature verification uses the browser's built-in Web Crypto API — crypto.subtle.importKey followed by crypto.subtle.verify — which is the same vetted cryptographic implementation your browser uses for TLS. HMAC algorithms take your shared secret; RSA, ECDSA and EdDSA take the public key in PEM or JWK form, or a JWKS from which the kid picks the key.
Because it runs in the page, your secret never travels anywhere. That distinction matters more here than almost anywhere else on this site: an online JWT tool that verifies server-side requires you to upload your signing secret to a third party, which is precisely the thing a signing secret must never do. If you can paste a production HMAC secret into a web page at all, it should be one that cannot leave it.
Since anyone holding a token can read it, treat the payload as public. Internal user identifiers, email addresses, subscription tiers and role names are all commonly placed there and all readable by the bearer. That is usually acceptable — but a password, an API key for another service, or a personal detail you are legally obliged to protect is not. If contents genuinely must be hidden from the bearer, you need JWE (encrypted tokens), which this page can produce and open, or, far more often, an opaque random session identifier that means nothing outside your own database.
iat, nbf and exp as UTC dates with relative time and the token's lifetime, a "not yet valid" status when nbf is in the future, and a warning when a value looks like milliseconds. Added a signer that creates HS256/384/512 test tokens locally.exp claim verification matrix and conditional status badge rendering.