JWT Decoder & Signature Verifier
Paste a JWT (JSON Web Token) to instantly decode its header and payload. Enter a secret or public key to verify its signature (HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512) — everything runs in your browser, nothing is sent to a server.
🔗 Share link encodes only the token text into the link itself (after the # in the address bar). Your secret/public key is never included. Nothing is sent to a server, but anyone with the link can read the token — don't share sensitive tokens this way.
The raw signature (base64url) will appear here.
The key is never sent to a server — verification happens entirely in your browser.
How to use
- Input: Paste a JWT string (header.payload.signature, separated by dots) into the box above.
- Check: The header and payload are decoded automatically and shown as a tree.
exp(expiration),iat(issued at), andnbf(not before) claims are shown alongside a human-readable date, and the banner above shows whether the token is expired. - Verify the signature: Below the raw signature value, enter a secret (HS256/384/512) or a PEM-formatted public key (RS256/384/512, PS256/384/512, ES256/384/512) and click "Verify signature" to check whether it's actually valid.
Everything runs inside your browser (JavaScript, Web Crypto API) — the token and key you enter are never sent to a server or stored. Curious why HS256 and RS256 verify differently, or what alg-related vulnerabilities show up in production? See the signature verification guide.
What is a JWT?
A JWT (JSON Web Token) is a token format for securely passing information between two parties: a header.payload.signature string with each part Base64URL-encoded and joined by dots. It's widely used for login authentication and API access tokens. The header and payload are only Base64URL-encoded (not encrypted), so anyone can decode them — as this tool does — which is why you should never put passwords or other sensitive data in the payload.
Frequently Asked Questions
Is my token sent anywhere?
No. All decoding happens in JavaScript inside your browser and is never sent to a server.
Does it verify the signature?
Yes. Below the signature panel, enter a secret (HS256/384/512) or a PEM-formatted public key (RS256/384/512, PS256/384/512, ES256/384/512) and the tool verifies the signature using your browser's built-in Web Crypto API. The key never leaves your browser. Tokens with alg: none have no signature at all and can't be verified — and should never be trusted.
Why do I get a "Not a valid JWT" error?
A JWT must have exactly 3 dot-separated parts (header, payload, signature). This error can happen if you accidentally included leading/trailing whitespace or pasted a truncated token.
The exp has passed, but the token still works.
This tool is display-only — actual expiration enforcement is up to the server/application that uses the token to check the exp claim.
How is a JWT different from session-based auth?
Session-based auth stores login state on the server (in memory or a database) and the client just carries a session ID. A JWT does the opposite — it packs the user's data into the signed token itself, so the server doesn't need to store any state (it's stateless) and just verifies the signature. The trade-off is that an issued JWT is hard to revoke immediately before it expires.
Why shouldn't I put a password or other sensitive data in a JWT?
The header and payload are only Base64URL-encoded, not encrypted — anyone can decode them just like this tool does. The signature only guarantees the content hasn't been tampered with; it doesn't hide the content.
Why do HS256 and RS256 need different verification inputs?
HS256/384/512 use a symmetric key (HMAC), so the issuer and verifier must share the same secret. RS256/384/512 (RSA), ES256/384/512 (ECDSA), and PS256/384/512 (RSA-PSS) are asymmetric — the issuer signs with a private key while anyone can verify with just the public key, no shared secret required. This tool reads the token's alg and automatically asks for the right kind of key.