JWT builder and verifier
Create signed test tokens with the claims you need, or check whether a token's signature and expiry are valid.
Creating and verifying JSON Web Tokens
JSON Web Tokens carry identity and permissions between services. When you build an API or test an integration you often need a token with specific claims: an expired one, one for a particular user, one with a custom scope. This tool builds, signs and verifies tokens entirely in your browser using the Web Crypto API, so you can generate test tokens without installing anything.
Edit the header and payload as JSON, choose an algorithm (HS256, HS384, HS512, RS256 or ES256) and supply the key: a secret for HMAC algorithms, or a PKCS#8 private key in PEM form for RSA and ECDSA. The token updates as you type. Switch to the Verify tab to paste a token and a secret or public key, and the tool tells you whether the signature is valid and explains the time claims: whether the token has expired, when it becomes valid, when it was issued.
Security notes
- Do not paste real production secrets or private keys into any website you do not control. This tool never uploads them, but your browser history and extensions can still see the page.
- The tool refuses to build unsigned (
alg: none) tokens and refuses to verify them. - Verification on a real server must pin the expected algorithm, check
exp,nbf,issandaud, and use a library, not hand-written code. - Keep token lifetimes short and use refresh tokens for long sessions.
To only read an existing token, use the JWT decoder on this site. HMAC signing uses SHA-256, SHA-384 or SHA-512; ES256 signatures use the raw 64-byte format JWT requires, not the DER format other tools produce.
Frequently asked questions
What are the three parts of a JWT?
A header (algorithm and type), a payload (the claims) and a signature, each Base64URL encoded and joined with dots. The header and payload are only encoded, not encrypted, so anyone can read them; the signature proves they were not changed.
HS256 or RS256?
HS256 uses one shared secret to sign and verify, so every service that verifies tokens can also forge them. RS256 and ES256 use a private key to sign and a public key to verify, which suits tokens verified by many services or third parties.
Why must the server pin the algorithm?
If a server accepts whatever alg the token declares, an attacker can switch to none or trick an RS256 verifier into treating the public key as an HMAC secret. Always configure the expected algorithm on the verifier.
Are the times in milliseconds?
No. exp, nbf and iat are numbers of seconds since 1 January 1970. Using milliseconds sets the expiry thousands of years ahead.