JWT Decoder & Generator
Decode a JWT to read its claims, generate a new token with custom payload, verify a signature, or create a signing secret, all in your browser, nothing sent anywhere.
Choose a Tool
Select a tool to decode, generate, verify JWT tokens or generate secrets
How to use the JWT tools
Four browser-based tools for reading, checking, creating and signing JSON Web Tokens.
- 01
Pick the tool for the job
Decoder to read a token, Verifier to check its signature against a secret, Generator to sign a test token, and Secret Generator to create a signing key. The table below matches common tasks to tools.
- 02
Paste a token or fill in the JSON
All four tools run in your browser. Tokens and secrets aren't sent to our server, though it's still wise to use test secrets rather than live production keys.
- 03
Check the claims as well as the signature
A token can be correctly signed and still be expired, issued for another app, or issued by the wrong server. Decode it and read exp, aud and iss too.
Which JWT tool to use
Each tool does one job. Here's the quickest way to pick:
| You want to | Use | Needs a secret or key? |
|---|---|---|
| See what's inside a token from an API call | JWT Decoder | No |
| Check a token wasn't edited after it was signed | JWT Verifier | Yes, the HMAC secret |
| Make a token to test an endpoint locally | JWT Generator | Yes, a test secret |
| Create a random signing key for a new app | JWT Secret Generator | No, it makes one |
| Verify an RS256 or ES256 token from Auth0, Cognito or Firebase | Not supported here | Needs the issuer's public key |
What a JWT is made of
A signed JWT is three base64url strings joined by dots: a header, a payload and a signature. The header names the algorithm, such as {"alg":"HS256","typ":"JWT"}. The payload holds claims: who the token is about (sub), when it expires (exp), who issued it (iss) and anything else the issuer adds, such as a role. The signature is computed over the first two parts, so changing a single character in either one makes it invalid.
The first two parts are only encoded, not encrypted. Anyone holding a token can read them, which is exactly what the decoder does. That's fine for user IDs and roles, but never put passwords, card numbers or other secrets in a payload. If the contents themselves must be hidden, that's a job for an encrypted JWE token, which has five parts instead of three.
Signing algorithms and what's supported here
The alg in the header falls into two families. HMAC algorithms use one shared secret for signing and verifying, which suits a single backend that issues and checks its own tokens. Asymmetric algorithms sign with a private key and verify with a public one, so many services can check a token without being able to create one. That's why identity providers use them.
| alg values | Method | Keys | Supported by these tools |
|---|---|---|---|
| HS256, HS384, HS512 | HMAC with a shared secret | Same secret signs and verifies | Yes |
| RS256, RS384, RS512 | RSA signature | Private key signs, public key verifies | No |
| PS256, PS384, PS512 | RSA-PSS signature | Private key signs, public key verifies | No |
| ES256, ES384, ES512 | ECDSA signature | Private key signs, public key verifies | No |
| EdDSA | Ed25519 signature | Private key signs, public key verifies | No |
The tools here work with the HMAC family only. The verifier shows an error naming the algorithm if you paste an RS256 or ES256 token, rather than claiming a result it can't check.
Where JWT tools help
Debugging a 401 from an API
Decode the bearer token your client sends and compare exp, aud and iss with what the API expects. One of the three is usually the cause.
Testing role-based access locally
Sign one token with an admin role and one with a viewer role, then hit the same endpoint with each to see that the checks work.
Setting up a new service's signing key
Generate a long random secret, put it in your secret store, and confirm with the verifier that tokens from your app check out.
Security mistakes to avoid with JWTs
Trusting the token's own alg header is the classic one. A server should decide which algorithm it accepts, rather than reading it from the token. Otherwise an attacker can send alg "none", or try to pass off an RS256 public key as an HS256 secret. Most libraries guard against this now, but only if you configure the allowed algorithm explicitly.
Long-lived tokens are the second. A JWT can't easily be revoked once issued, so keep access tokens short, often 5 to 15 minutes, and use refresh tokens for longer sessions. And think about where the browser stores them: localStorage is readable by any script on the page, so an httpOnly cookie is often the safer home for a session token.
Refresh tokens and logging users out
Because a server can check a JWT without looking anything up, it also can't easily cancel one. A token stolen five minutes before it expires keeps working for those five minutes. That's the reason for the short access-token lifetime, and for pairing it with a refresh token: a longer-lived credential, usually stored in an httpOnly cookie, that's sent only to the auth server to get a new access token.
Logging out then means deleting the refresh token on the server, so no new access tokens can be issued. For cases where even a few minutes matter, such as a compromised account, keep a short deny list of revoked token IDs (the jti claim) and check it on each request, accepting the small cost of a lookup.
Frequently asked questions
For more on signing, verification and safe storage, read the JWT security and verification guide.