Are the secret or the generated token sent to a server?

No. Signing happens in your browser with the Web Crypto API. The secret, the header, the payload and the token aren't sent to any server, aren't included in analytics events and aren't saved when you close the page.

Can I use the production secret here?

Don't. Even with everything running in the browser, whoever has the production secret can issue a token for any user. For testing, set up a dedicated secret in the staging environment or use the one generated here.

I generated a token and the API rejected it. What should I check?

Check that the secret matches the backend's, including whether it's stored as Base64 there; that the algorithm configured in the API matches the token's; that exp is in the future and nbf in the past; and that iss and aud match what the API expects.

Why can't I generate RS256 or ES256 tokens?

Because it would mean pasting a private key into the browser. That kind of key should stay on the server that issues tokens. For APIs that validate RS256, ask the staging provider for a token and use the JWT Decoder to check its claims.

How do I set when the token expires?

Use the exp +15 min, +1 h, +1 day or +7 days shortcuts, which count from now, or edit exp in the JSON as Unix seconds. The exp in the past shortcut creates an already expired token.

It's a unique token identifier. APIs use jti to block reuse or to revoke one specific token. The shortcut generates a new UUID v4 on every click.

When should I check the Base64 secret option?

When the backend stores the secret Base64 encoded and decodes it before use, as some Spring setups and Java libraries do. If the backend uses the secret text directly, leave the option unchecked.

JWT Generator

Build the header and claims, enter the secret and copy a JWT signed with HS256, HS384 or HS512. Use it to test login, access profiles and expiration without depending on the identity provider.

For testing only. Use a staging secret or the random one generated here, never the production secret. Signing happens in your browser and nothing is sent to a server.

Algorithm

HMAC with SHA-256, SHA-384 or SHA-512. Whoever validates the token needs the same secret.

Test profile

Header

The header's alg follows the selected algorithm.

Payload (claims)

Add claim

Secret

The secret is Base64 encoded

Generated token

The token shows up here once the header, payload and secret are valid.

Got a token and want to see what's inside it?

Open the JWT Decoder

How to use the JWT Generator?

Build the claims

Pick a test profile or edit the payload JSON. The shortcuts add a relative exp, iat, jti and other common claims.

Enter the secret

Use the same secret your test backend is configured with, or generate a random one sized for the algorithm.

See the token

The token is signed on every change, no button needed. The summary shows when it expires.

Copy and test

Copy the token or the ready Authorization header and use it in Postman, curl or an automated test.

Why generate a test JWT

Logging in through the identity provider for every test scenario isn't always practical. With a token generated here you can hit the API with any profile you need, including cases that are hard to reproduce, like an already expired token or one missing a role. It works when your test backend validates tokens with an HMAC secret you know.

Scenarios worth a test token

An admin and a regular user with the same sub, to check that the route blocks users without the role
An expired token, to make sure the API returns 401 and the front end asks for a new token
A token with nbf in the future, to test rejection of a token that isn't valid yet
A token without the roles claim or with an incomplete scope, to test the 403 response
A token with another API's aud, to confirm the API doesn't accept someone else's token
A signature made with a different secret, to confirm the API rejects a tampered token

HS256, RS256 and ES256: what's the difference

HS256 uses a shared secret: the same value signs and verifies, so whoever validates can also issue tokens. RS256 uses an RSA key pair: the provider signs with the private key and APIs verify with the public one, which can be published. ES256 does the same with elliptic curves, with much smaller keys and signatures. Providers such as Keycloak, Auth0 and Cognito sign with RS256 by default.

This generator only signs with HMAC on purpose. Signing RS256 or ES256 would mean pasting a private key into the browser, and a private key shouldn't leave the server that issues the tokens. To test an API that validates RS256, get the token from the provider's own staging environment.

How the HMAC signature is computed

The generator encodes the header and payload in base64url, joins them with a dot and computes the HMAC of that text with the secret. The result, also in base64url, becomes the third part of the token. That's why any change to the payload, even a space, produces a different signature, and why the backend rejects a changed token unless the secret is known.

Secret size

RFC 7518 asks for a secret at least as long as the hash output: 32 bytes for HS256, 48 for HS384 and 64 for HS512. A secret like password123 signs just fine, but it can be brute forced from a captured token. The Random secret button creates one with the minimum size for the selected algorithm.

How to send the token in a request

The most common way is the Authorization header with the Bearer prefix. The Copy Authorization button copies the ready line. With curl it looks like this:

curl -H "Authorization: Bearer YOUR_TOKEN" https://api.staging.example.com/orders

Frequently Asked Questions about the JWT Generator

Common questions from people generating JWTs for testing.