JWT Decoder & Generator
Paste a JSON Web Token to decode its header and payload, verify its signature (HS256/384/512, RS256/384/512, or ES256/384), and check standard claims like exp and aud. Runs entirely client-side — your token never leaves your browser.
Generate a New Token (HMAC)
How to use it
- Paste a compact JWT and select Decode to inspect its header, payload, and registered time claims.
- For an
HS*token, provide the shared secret. For anRS*orES*token, paste a public PEM key or JWKS JSON. - Optionally enter the expected audience and issuer, plus an allowed clock-skew tolerance.
- Review signature and claim results separately. A readable token is not automatically trusted.
Decoding is not verification
A compact signed JWT normally contains three Base64url segments: header, payload, and signature. Anyone who has the token can decode the first two segments; they are encoded, not encrypted. Verification uses the signature and the correct secret or public key to determine whether those segments were changed after the issuer signed them.
Cryonel always shows the decoded JSON when the token structure is readable. It labels the signature as unverified until appropriate key material is supplied. Never treat claims such as sub, role, or email as trustworthy merely because they decode successfully.
JWT claim checks
The claims panel converts exp, nbf, and iat Unix timestamps into readable dates. It flags expired tokens, tokens that are not valid yet, and issue times unexpectedly far in the future. Optional audience and issuer inputs let you compare aud and iss with the values expected by your API. Clock skew should remain small and should reflect the maximum real difference between system clocks.
Claim checks support debugging but do not replace server-side authorization. An application must still enforce the correct algorithm, trusted issuer, expected audience, key rotation policy, permissions, and revocation behavior.
PEM and JWKS verification
For RSA and ECDSA tokens, paste only public key material. When a JWT header contains kid, Cryonel requires a JWKS entry with the same identifier. It will not silently try the first key when that identifier is missing. If the token has no kid, the first supplied JWKS key is used, so a single-key JWKS is clearest for that case.
Cryonel does not fetch a JWKS URL because doing so would create a network request from the tool. Copy the JSON from the issuer separately and paste it into the verifier. The matching and Web Crypto verification then happen locally.
Common JWT verification failures
- Signature does not match: the secret or public key is wrong, the token changed, or the selected algorithm does not match the issuer.
- JWKS key not found: the header’s
kidis absent from the pasted key set, often because the issuer rotated keys. - Token expired: the current time is later than
exp, after any configured skew. - Audience or issuer mismatch: the token was minted for a different service or identity provider.
- Malformed token: the compact value does not contain three valid Base64url segments with JSON header and payload.
The HMAC generator is intended for development fixtures and interoperability tests. Avoid pasting production secrets into any third-party page even when processing is local, and never include passwords, private keys, or other confidential values in a JWT payload.
Frequently Asked Questions
Which algorithms are supported?
Verification and generation: HS256, HS384, HS512 (shared secret). Verification only: RS256, RS384, RS512, ES256, ES384 (public key). EdDSA (Ed25519) isn't supported — browser support for it is still inconsistent, and we'd rather leave it out than ship a check that silently fails in some browsers.
Can I verify against a JWKS URL?
Not by URL — fetching a remote JWKS would mean this page makes a network request, which breaks the "nothing leaves your browser" guarantee every other tool on Cryonel follows. Instead, paste the JWKS JSON directly (copy it from your identity provider's /.well-known/jwks.json endpoint) and it's matched locally.
What does the "alg: none" warning mean?
A token with "alg":"none" has no signature at all — anyone can create one with arbitrary claims. It's a well-known JWT vulnerability class; a backend that accepts these can be trivially impersonated. Cryonel decodes them but never treats them as verified.
Why does the signature matter?
The signature lets you confirm the token was issued by the server and hasn't been tampered with. The header and payload are readable by anyone (they aren't encrypted), so never put sensitive data in the payload.
Is it safe to enter my secret or key on this site?
Nothing is sent to a server — all computation happens in your browser via the Web Crypto API. That said, avoid entering production secrets into third-party tools.