JWT Decoder, Verifier & Encoder
betaDecode a JSON Web Token, check its expiry, verify the signature with a secret or public key, or sign a new one
How it works
Paste a token (a leading “Bearer ” is fine). The three base64url parts are decoded and colour-coded, the header and payload are shown as JSON, and the registered claims are explained: iss, sub, aud, jti, and the time claims exp, nbf and iat as local and UTC dates with a relative time, so you see at a glance whether the token is expired, not yet valid, or good for another few hours. To verify the signature, enter the shared secret for HS256/384/512 (as text or base64) or paste the public key for RS256/384/512, PS256/384/512, ES256/384/512 or EdDSA — as PEM, a single JWK, or a whole JWKS, from which the key is picked by the token's kid. Verification uses your browser's WebCrypto; secrets and keys never leave the page. Tokens with alg “none” are flagged as unsigned. Encode & sign does the reverse: edit the header and payload JSON, set iat/exp with one click, provide a secret or private key (or generate a key pair in the browser), and get a signed token you can decode and verify right away. Share links carry the token compressed in the URL fragment, never a secret.
Questions
Which algorithms can it verify and sign?
HS256, HS384, HS512 (HMAC with a shared secret); RS256/384/512 (RSASSA-PKCS1-v1_5); PS256/384/512 (RSA-PSS); ES256/384/512 (ECDSA on P-256/384/521); and EdDSA (Ed25519, where the browser supports it). Tokens with alg none are decoded but flagged as unsigned.
Is it safe to paste a real token or secret?
Decoding and verification run entirely in your browser with WebCrypto; nothing is sent to a server. Secrets and keys are kept in memory only and are never written to the URL. The token is only placed in a link if you press Share, and then compressed into the URL fragment.
What key formats are accepted?
PEM public keys (BEGIN PUBLIC KEY / SPKI) for verifying, PEM private keys (BEGIN PRIVATE KEY / PKCS#8) for signing, a JWK, or a JWKS document — the key whose kid matches the token header is used. PKCS#1 blocks (BEGIN RSA PUBLIC KEY) and X.509 certificates need converting first; the tool tells you how.
How is the expiry shown?
exp, nbf and iat are converted from Unix seconds to your local time and UTC, with a relative time such as “expires in 2 h 14 min” or “expired 3 d ago”. The header shows an overall status: valid, expired, not yet valid, or no expiry.
Can I create a token?
Yes. In Encode & sign, edit the header and payload, enter an HS secret or a private key — or generate an RSA/EC/Ed25519 key pair in the browser — and sign. The result can be decoded and verified in one click, and the public half of a generated pair is available to copy.
Why does verification say “can't verify”?
The key couldn't be used: wrong format, a JWKS without the token's kid, a public key given where a private one is needed, or an algorithm the browser doesn't implement. The message says which.