What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It is widely used for authentication and authorization, once you log in, the server hands you a token that your app sends with each request to prove who you are. A JWT is made of three parts joined by dots: header.payload.signature. The header and payload are simply Base64url-encoded JSON (not encrypted), so anyone can decode and read them, which is exactly what this tool does.
How to use this JWT decoder
- Paste your token into the input box, it usually starts with
eyJ. - The Header and Payload are decoded and pretty-printed automatically as you type.
- Inspect the claims, common ones include
sub(subject),iat(issued-at),exp(expiry) andiss(issuer). - Copy either the header or payload JSON with one click, or Clear to start over.
- Verify the signature (optional): for HS256/HS384/HS512 tokens, enter the secret key. For RS256/RS384/RS512/ES256/ES384/ES512, paste the issuer's public key. Everything runs in your browser with the Web Crypto API, nothing is uploaded.
Tip: iat and exp are Unix timestamps (seconds since 1970). An expired exp means the token would be rejected by a server even though it still decodes fine here.
Decoding vs. verifying a JWT
Decoding a JWT and verifying a JWT are two different things. Decoding just reads the header and payload, anyone can do that without any secret. Verifying proves the token hasn't been tampered with, and it requires the signing secret (for HMAC algorithms likeHS256) or the issuer's public key (for RSA/ECDSA algorithms like RS256 or ES256). This tool does both: it decodes automatically, and it verifies the signature client-side (via the browser's Web Crypto API) if you supply the secret or public key. A token with alg: none claims to have no signature at all, a known vulnerability class if a server actually accepts it, so this tool flags it instead of pretending to verify it. If you don't have the secret or public key handy, you should still never treat a decoded payload as proof that a token is authentic or still valid; verify it, ideally on your server, before trusting any claim.
Frequently asked questions
Does this verify the signature?
Yes, optionally. It always decodes the header and payload. For HS256/HS384/HS512 tokens, enter the secret key to verify. For RS256/RS384/RS512/ES256/ES384/ES512 tokens, paste the issuer's public key. Other algorithms, and alg: none, are flagged rather than guessed at. Production systems should still verify signatures server-side.
Why does my token decode but still get rejected by my API?
Decoding always works on well-formed tokens, but an API also checks the signature and claims like exp. An expired or wrongly-signed token decodes fine here yet is still rejected by the server.
Does this verify the JWT signature?
It decodes the header and payload automatically, and it can also verify the signature. For HS256, HS384 and HS512 tokens, enter the signing secret. For RS256, RS384, RS512, ES256, ES384 and ES512 tokens, paste the issuer's public key. Other algorithms, and alg: none, are flagged instead of guessed at.
Is it safe to decode a real access token here?
Treat any token like a password and avoid pasting it into tools you do not trust.