🔐 Developer Tools
Build and sign a JSON Web Token in seconds. Edit the header and payload, pick an algorithm, add your secret or private key, and get a ready-to-use signed JWT — all privately in your browser.
HMAC uses a shared secret. Switch algorithm to RS/PS/ES to sign with a PEM private key.
Generate signed tokens with the Web Crypto API — no server, no libraries, no exposure of your keys.
HMAC (HS), RSA (RS/PS), and ECDSA (ES) are all supported for real, verifiable signatures.
Add iat, exp, and nbf with one click, and format your JSON instantly.
Your secret, private key, and generated token never leave your device.
ToolAdda base64url-encodes your header and payload, joins them with a dot, and signs that string with your secret or private key using the selected algorithm. The signature is appended to produce a complete header.payload.signature token that other services can verify.
All signing happens locally in your browser. Your secret, private key, payload, and generated token are never uploaded, logged, or stored on any server.
Pick an algorithm, edit the payload with your claims, enter your secret or private key, and the signed token appears instantly on the right.
Yes. Signing runs entirely in your browser with the Web Crypto API — nothing is sent anywhere.
A PEM private key in PKCS#8 format (begins with -----BEGIN PRIVATE KEY-----).
Yes — open it in our JWT Debugger and check the signature with the matching secret or public key.
No. The payload is only encoded, not encrypted, so anyone can read it. Keep only non-sensitive claims.
HS256 is common for simple shared-secret setups; RS256 and ES256 are preferred when different parties verify with a public key.
The JWT Encoder by ToolAdda lets developers quickly craft and sign JSON Web Tokens for testing authentication, APIs, and integrations. Edit the claims, choose the signing algorithm, and generate a valid token you can paste into requests or verify elsewhere — without installing anything or exposing your keys to a server.
A JSON Web Token is three Base64url segments joined by dots:
header.payload.signature. The first two are simply JSON that has been
encoded, not encrypted — anyone holding the token can read them.
The signature is the whole point. It does not hide anything; it guarantees that nobody has edited the payload in transit. Change one character of the payload and the signature no longer matches.
This is the mistake that causes real breaches, so it is worth being blunt about. Base64 is encoding, not encryption. Anyone who obtains the token can decode the payload in one step and read every claim inside it.
So never put anything secret in a JWT payload: no passwords, no card numbers, no personal data you would not hand to whoever holds the token. Put an identifier in the token and keep the sensitive data on your server, where the token is used to look it up.
| Family | How it works | Use when |
|---|---|---|
| HS256 / HS384 / HS512 | One shared secret both signs and verifies | The same system issues and checks the token. |
| RS256 / RS384 / RS512 | A private key signs, a public key verifies | Other parties must verify without being able to issue. |
| ES256 / ES384 | Elliptic curve — same split, smaller keys | Same as RS, when you want shorter signatures. |
The distinction that matters: with HS, anyone who can verify a token can also mint one, because it is the same secret. With RS and ES, you can hand out the public key freely and still be the only party able to issue tokens. If a third party needs to check your tokens, you want RS or ES.
If you use HS, the secret must be genuinely long and random. A short or guessable secret can be brute-forced offline from a single captured token, at which point anyone can forge tokens that your system will trust.
exp — expiry. Always set one. A token without an expiry is valid forever, including after it leaks.iat — issued at. Useful for auditing and for invalidating everything issued before a certain moment.sub — subject: who the token is about.iss — issuer: who created it, so a verifier can reject tokens from elsewhere.aud — audience: which service the token is meant for, so it cannot be replayed against another.nbf — not before, if the token should only become valid later.Short expiries are the single most effective protection. A leaked token that expires in fifteen minutes is a much smaller problem than one that lasts a year.
The token is built and signed on your device using the browser's own Web Crypto implementation. Your secret or private key is never transmitted, which is the only acceptable arrangement for a tool like this — a signing key pasted into a remote service should be considered compromised from that moment.
Even so, treat tokens made here as test tokens. For production signing, use your own infrastructure and keep keys in a secrets manager rather than a browser tab.
Three Base64url segments joined by dots: header, payload and signature. The header names the signing algorithm, the payload holds the claims, and the signature proves the first two parts have not been altered since they were signed.
No, and this is the single most important thing to understand. Base64 is encoding, not encryption. Anyone holding the token can decode the payload and read every claim in it. The signature proves the token has not been tampered with; it does not hide anything.
Anything you would not hand to whoever holds the token: passwords, card numbers, personal data. Put an identifier in the token and keep the sensitive data on your server, where the token is used to look it up.
HS256 when the same system both issues and verifies tokens, because it uses one shared secret for both. RS256 or ES256 when other parties need to verify tokens without being able to create them, because those split signing and verification into a private and a public key.
With HS256, anyone who can verify a token can also mint one — it is the same secret. With RS256 you can publish the public key freely and remain the only party able to issue tokens. If a third party has to check your tokens, you want RS256 or ES256.
Long and genuinely random — treat it like a cryptographic key rather than a password. A short or guessable secret can be brute-forced offline from a single captured token, after which anyone can forge tokens your system will accept.
No. The token is signed on your device using the browser's own Web Crypto implementation, so the key never leaves the page. A signing key pasted into a remote service should be treated as compromised from that moment.
Treat them as test tokens. For production, sign on your own infrastructure and keep keys in a secrets manager rather than a browser tab. This tool is for building, inspecting and debugging tokens during development.
An expiry (exp) above all — a token without one is valid forever, including after it leaks. Beyond that, iat for issued-at, sub for who the token is about, iss for who issued it, and aud so the token cannot be replayed against a different service.
As briefly as your flow allows. Short expiries are the most effective protection there is: a leaked token that expires in fifteen minutes is a far smaller problem than one lasting a year. Use refresh tokens for longer sessions.
Not directly, and this is the main trade-off of the format. A signed token stays valid until it expires, because verification does not involve your server. If you need revocation, keep a denylist of token identifiers or use short expiries with refresh tokens.
Usually one of four things: it has expired, the verifying side has a different secret or key, the algorithm does not match what the verifier expects, or the audience or issuer claim does not match. Decode the payload first — the reason is normally visible in the claims.
This tool builds and signs a new token from claims you provide. A decoder takes an existing token apart so you can read its header and payload and check its signature. Both are linked from the site.
Yes, with no sign-up and no limit. Everything runs in your browser.