🎟️ JWT (JSON Web Token) Builder & Simulator
A JWT builder that signs for real with Web Crypto HMAC-SHA256, plus decode and verify. Runs in your browser — but never paste a live secret.
{
"alg": "HS256",
"typ": "JWT"
}Signing happens in this tab and nothing is uploaded — but treat any secret you paste into any web page as compromised and rotate it. Use a throwaway value here.
What JWT (JSON Web Token) Builder & Simulator Does
A JSON Web Token is three base64url-encoded parts joined by dots: a header saying which algorithm signed it, a payload of claims, and a signature over the first two. The signature is the whole point — it lets a server confirm that a token it issued has not been altered, without storing anything about it.
The part that trips people up is that a JWT is encoded, not encrypted. Anyone holding a token can decode the payload and read every claim in it, with no key and no effort. That is by design, and it means a JWT is the wrong place for anything you would not put in a URL.
This tool signs for real, using the browser's Web Crypto HMAC implementation, so the tokens it produces verify against any standard library. It also decodes and verifies, which is the more common task — checking why a token was rejected usually means looking at its claims and its expiry.
One honest caution about any online JWT tool, this one included. The signing happens in your tab and nothing is uploaded, but a secret you paste into a web page has been typed into a browser, may be in your clipboard history, and is one autofill or extension away from somewhere else. Use throwaway values here, and treat a production secret you have pasted anywhere as one to rotate.
How to Use JWT (JSON Web Token) Builder & Simulator
- Edit header JSON and payload claims JSON
- Enter your HMAC secret key
- Copy the generated Base64URL-encoded JWT token
Formula Used by JWT (JSON Web Token) Builder & Simulator
How a signed token is assembled
token = base64url(header) + "." + base64url(payload) + "." + base64url(HMAC(secret, header + "." + payload))
- base64url
- standard base64 with + and / swapped for - and _, and trailing = removed
- HMAC
- a keyed hash — HS256, HS384 and HS512 use SHA-256, SHA-384 and SHA-512
- the signature covers
- the encoded header and payload only, joined by a dot — not the raw JSON
Worked example
Header {"alg":"HS256","typ":"JWT"} and payload {"sub":"1234567890"}.
- Each is minified, then base64url encoded
- The two encoded strings are joined with a dot — this is the signing input
- HMAC-SHA256 over that string with your secret produces 32 bytes, base64url encoded as the third part
Result: A token any JWT library will verify with the same secret. Changing a single character of the payload invalidates it.
The registered claims
All optional, all conventional. A library will usually check exp and nbf for you; the rest are yours to validate.
| Claim | Name | What it holds |
|---|---|---|
| iss | Issuer | Who created the token |
| sub | Subject | Who the token is about — usually a user id |
| aud | Audience | Who it is intended for; reject tokens meant for another service |
| exp | Expiry | Seconds since 1970, after which the token is invalid |
| nbf | Not before | Seconds since 1970, before which it is invalid |
| iat | Issued at | When it was created |
| jti | JWT ID | A unique id, used to detect replay |
Algorithms
| Family | Key | Use when |
|---|---|---|
| HS256 / HS384 / HS512 | One shared secret | The same service issues and verifies. Simple, and everyone who can verify can also forge. |
| RS256 / RS384 / RS512 | RSA private key signs, public key verifies | Others need to verify without being able to issue — the usual choice for identity providers. |
| ES256 / ES384 / ES512 | ECDSA private and public key | Same split as RSA, with much smaller keys and signatures. |
| none | No key at all | Never. It exists in the specification and accepting it is a well-known critical vulnerability. |
How to Read Your Result
Never put a secret in the payload
The payload is readable by anyone holding the token — decoding it needs no key. Email addresses, internal ids and role names are common and usually acceptable; passwords, card numbers, API keys and personal data are not.
Verify the algorithm, do not trust the header
The classic JWT attack is changing the header to "alg":"none" or swapping RS256 for HS256 and signing with the public key. A verifier must decide which algorithm it accepts and check the token against that, rather than doing whatever the token asks. Any library worth using makes you name the expected algorithm.
Expiry is the only revocation you get
A JWT is valid until it expires, because nothing is stored server-side to invalidate. That is the trade for statelessness. Keep access tokens short-lived — minutes, not weeks — and use a refresh mechanism if you need sessions that can actually be ended.
HMAC secrets must be long
HS256 takes any byte string, so a short password will "work" and be trivially brute-forceable offline by anyone who captures one token. Use at least 256 bits of randomness, generated rather than chosen.
Limitations & Accuracy Notes
- Signs and verifies HMAC algorithms only. RS and ES need a key pair, which is not something to paste into a web page.
- Expiry is checked against your device clock, so a wrong clock gives a wrong answer.
- It validates the signature and the time claims, not your application rules — audience, issuer and scope are yours to check.
- The payload is displayed as-is; it is not scanned for anything sensitive.
- Everything runs in your browser and nothing is uploaded, but a secret pasted into any web page should be treated as compromised.
Frequently Asked Questions
What are the three parts of a JWT token?
Is it safe to test secret keys in this tool?
Can I build a token here that a real server will accept?
What should never go in a JWT payload?
Which claims should I include?
Should I use HS256 or RS256?
How long should a token last?
Is my token sent anywhere?
References & Further Reading
- RFC 7519 — JSON Web Token — The specification, including the registered claims listed above
- RFC 7515 — JSON Web Signature — How the signature is computed over the encoded header and payload
- RFC 8725 — JSON Web Token Best Current Practices — The IETF write-up of the algorithm-confusion and "alg: none" attacks described above, and what verifiers must do about them