Which algorithm signed it
A small JSON object naming the signing algorithm in alg and usually the type in typ. It may also carry kid, a hint telling the recipient which of several keys to check against.
Local-first
Decode and verify JWTs without uploading them.
Paste a token to read its header and payload, check the signature against your key, or sign a new one. Everything runs in your browser through WebCrypto — your tokens and your keys never leave this device.
Encoded token
Header
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9Payload
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQSignature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cDecoded
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}Claims
No expiry setNo "exp" claim, so this token never expires on its own. That is usually a mistake.
| Claim | Value |
|---|---|
| sub | 1234567890Subject — who or what the token is about, usually a user id. |
| name | John DoeCustom claim — defined by whoever issued the token. |
| iat | 2018-01-18T01:30:22Z — 1516239022 (3122 days ago)Issued at — when the token was created. |
Build a token
The alg field is set from the algorithm you choose above.
Signed token
Uses the algorithm and key from the Key panel below.
Key
HMAC uses the same shared secret to sign and to verify.
Not checked yet — press Verify signature.
What the three parts actually are
A JWT is three base64url strings joined by dots. Only the third one involves cryptography — and none of them involve encryption.
The claims — readable by anyone
The actual statements: who the token is about, who issued it, when it expires. This is encoded, not encrypted. Anyone holding the token can read it, so it must never contain a password or a secret.
Proof it was not edited
The first two parts are signed with a key. Changing a single character of the payload invalidates it. The signature proves integrity and origin — it does not hide anything.
Questions
Is it safe to paste a production token here?
Yes, in the sense that nothing is transmitted. Decoding, verification and signing all run in your browser through the WebCrypto API, and there is no server to receive anything. You can confirm it: open your browser’s network panel, paste a token, and watch that no request carries it. Most online JWT tools POST your token to a backend.
Does decoding a JWT require the secret?
No, and this is the part people are most often surprised by. The header and payload are only base64url encoded, not encrypted, so anyone holding the token can read every claim inside it. The signature does not hide the contents — it only proves they have not been changed. Never put a password or anything private in a JWT payload.
What does “Invalid signature” actually tell me?
That the token and the key you supplied do not match. Either you have the wrong key, or the token was altered after it was signed. It does not tell you which — that is the point of a signature. Check the algorithm in the header matches the one selected, since verifying an RS256 token with an HMAC secret will always fail.
Why is alg "none" dangerous?
It means the token carries no signature at all, so anyone can edit the payload and it stays “valid”. Several libraries historically accepted it by default, which let an attacker change a user id to an admin id. If you see it outside a test fixture, treat it as a vulnerability.
Which key formats does this accept?
HMAC algorithms take a plain or base64-encoded shared secret. RSA and ECDSA take a PEM public key for verifying and a PEM private key for signing, or a JWK for either. PKCS#1 keys (BEGIN RSA PRIVATE KEY) need converting to PKCS#8 first, because WebCrypto only reads PKCS#8.
Are my keys stored anywhere?
No. Keys are imported into WebCrypto as non-extractable, which means even this page cannot read them back out once imported, and nothing is written to storage or sent anywhere. Closing the tab discards everything.