Free JWT Generator Online

The JWT Generator is a free online tool that creates and signs JSON Web Tokens for authentication testing and development purposes.

Yes, it is completely free with no registration required. All token generation happens client-side in your browser, and your secret key is never transmitted.

The JWT Generator supports HS256, HS384, HS512, and other common signing algorithms used in JWT authentication.

Absolutely. The JWT Generator processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the JWT Generator is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the JWT Generator in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The JWT Generator works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

Both produce a SHA-based signature, but the key model is completely different. HS256 (and HS384/HS512) is HMAC: a single shared secret signs the token and verifies it, so every party that checks the signature could also forge one. RS256 (and RS384/RS512) is RSA-based and asymmetric: a private key signs the token while a separate public key verifies it, so you can hand the public key to many services without letting them mint tokens. As a rule, use HMAC when one trusted backend both issues and validates tokens, and use RSA when verifiers shouldn't hold the signing key, such as third parties or a public API. This generator signs with all six algorithms using the browser's Web Crypto API, and can produce a 2048-bit RSA key pair for you to test RS256 end to end.

Yes. A JWT is signed, not encrypted, so anyone holding the token can decode and read its payload. The header and payload are only Base64URL-encoded — not ciphered — and any decoder, including this one, reverses that instantly without a key. The signature only guarantees the token hasn't been altered since it was issued; it does not hide the contents. That means you should never place passwords, API secrets, or sensitive personal data in JWT claims. Treat the payload as public information that just happens to be tamper-evident. If you genuinely need the contents hidden, you need an encrypted token (JWE), which is a separate mechanism. Paste any token into this tool's decoder to see exactly what a recipient would read and confirm nothing sensitive is exposed.

These are registered time claims stored as Unix timestamps in seconds. The iat (issued-at) claim records when the token was created. The exp (expiration) claim sets when it stops being valid — verifiers reject the token once the current time passes exp. The nbf (not-before) claim is the opposite: the token is invalid until the current time reaches nbf, which is useful for tokens that should activate later. Keeping exp windows short limits the damage if a token leaks, since refresh tokens handle longer sessions. This generator fills iat and exp automatically with one-click presets of 15m, 1h, 24h, 7d, 30d, and 1y, and lets you toggle an nbf claim on. When you decode a token here, it also tells you whether it has expired and how long until or since exp.

Verification recomputes the signature over the token's header and payload using the correct key and checks that it matches the signature attached to the token. For HMAC algorithms (HS256/384/512) you supply the same shared secret used to sign; for RSA algorithms (RS256/384/512) you supply the matching public key in PEM format. If the recomputed value matches, the token is authentic and untouched; if not, it was altered or signed with a different key. Verification alone isn't enough, though — production code should also check exp, nbf, iss, and aud before trusting a token. Paste a token into this tool's decoder, provide the secret or public key, and it verifies the signature cryptographically in your browser using Web Crypto, so the result reflects real validation rather than a guess.

A token can be perfectly well-formed yet still fail validation for reasons unrelated to its claims. The most common cause is a secret or key mismatch: even a trailing space, wrong character encoding, or a Base64 secret pasted as raw text changes the signature and makes verification fail. Another is the algorithm — verifying an RS256 token with an HMAC secret, or vice versa, will never match. Time claims also matter: an expired exp or a future nbf marks the token invalid even when the signature is correct. Finally, any edit to the header or payload after signing breaks the signature, since it's computed over both. Use this tool to decode the token, confirm the algorithm in the header, check the exp and nbf timestamps, and re-verify with the exact secret or public key to pinpoint which of these is the culprit.