Request a trial
Menu
Products
Solutions
ERP
Authentication
Apps
LearnDocsWhy SSOGENRequest a trial

SSOGEN / Free tools / JWT Generator and Encoder: Sign a Token in Your Browser

Free tool

JWT Generator and Encoder: Sign a Token in Your Browser

A JWT generator builds a signed JSON Web Token from a header, claims and a key. This JWT encoder signs with HS256 to ES384, makes test keys, checks the claims and verifies its own signature, all on your computer.

Request a trial

Generate a JWT here

Choose an algorithm, edit the claims and supply a secret or a test key pair.

Select Generate JWT to get the compact token, the decoded parts and a list of checks. To see a complete result first, select Fill in an Acme example.

Times are NumericDate values: whole seconds since 1970-01-01T00:00:00Z. The buttons below set iat, nbf and exp from the current time.

Set iat, nbf and exp from now:

Private by design. The token is signed in this page with the Web Crypto API. Keys and secrets are made here with a cryptographic random generator and never leave the page. There is no "none" algorithm: every token this tool makes is signed. Use test keys, not production ones.

Free, in your browser: nothing is uploaded and there is no “none” algorithm. Use test secrets and test keys only.

What a JWT generator does

A JWT generator encodes a header and a set of claims as base64url, joins them with a dot and signs the result.

The output is the compact form of a JSON Web Signature, defined in RFC 7515: header.payload.signature. A verifier recomputes the signature with the same secret or the matching public key.

This JWT encoder also does the checking a plain signer skips:

  • Self-check. It verifies the new signature with the matching key.
  • Secret length. It warns about a secret that is too short.
  • Claims. It flags claims that a verifier would reject.

Choose an algorithm

Algorithm Key you provide What it is Signature
HS256, HS384, HS512 One shared secret HMAC with SHA-256, 384 or 512 Same input always gives the same token
RS256, RS384, RS512 RSA private key (2048 bits or more) RSASSA-PKCS1-v1_5 Same input always gives the same token
PS256 RSA private key RSASSA-PSS, salt as long as the hash output Different each time
ES256, ES384 EC private key on P-256 or P-384 ECDSA Different each time, 64 or 96 bytes
  • Shared secret (HS). Use it only when the signer and the verifier are the same system or trust each other fully, because anyone who can verify can also sign.
  • Key pair (RS, PS, ES). Use it when many services verify tokens from one issuer: they need only the public key, which the issuer can publish as a JWKS.
  • No none option. RFC 8725, section 3.2, says an unsigned algorithm should be used only when other means protect the token.

What each field sets

  • Signing algorithm becomes the alg header parameter. A verifier should accept only the algorithms it expects, and use each key with exactly one algorithm (RFC 8725, section 3.1).
  • Token type becomes typ. JWT is the usual value.
  • Key ID becomes kid. A verifier uses it to pick the right key from a key set. Leave it empty for a single-key test.
  • Payload holds the claims. iss names the issuer, sub the subject, aud the intended audience, and exp, nbf and iat the times.
  • Time buttons write iat and nbf as now and exp as now plus 5 minutes, 1 hour or 1 day, as whole seconds. RFC 7519 defines these values (NumericDate) as seconds since 1970-01-01T00:00:00Z.

Secrets and key pairs

For HS256, HS384 and HS512, RFC 7518, section 3.2 requires a key at least as long as the hash output: 32, 48 or 64 bytes.

The tool counts the bytes of your secret and marks a shorter one as an error.

Generate a random secret fills the field with random bytes from crypto.getRandomValues, written as base64url.

Do not use a memorable password as an HMAC key. RFC 8725, section 3.5, forbids it.

For RS, PS and ES, Generate a test key pair makes the keys with Web Crypto and shows:

  • the private JWK, which stays in the key box so you can reuse it for later tokens;
  • the public JWK, which a verifier uses (with use, alg and your kid added);
  • the public key in PEM form (SPKI), for libraries that read PEM.

You can also paste an existing private JWK. The tool checks that its key type and curve fit the algorithm: ES256 needs P-256, ES384 needs P-384, and the RSA algorithms need an RSA key.

A worked example

RFC 7515, Appendix A.1 signs these claims with HS256:

{"iss":"joe",
 "exp":1300819380,
 "http://example.com/is_root":true}

The key is the 64-byte secret AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow (base64url), and the signature is dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk.

  • HS256 and RS256. The signing code in this tool reproduces that signature and the RS256 example in Appendix A.2 byte for byte when given the same header text, payload text and key.
  • ES256. It verifies the ES256 example in Appendix A.3, which cannot be compared byte for byte because ECDSA signatures are randomised.

Note the claim exp of 1300819380. It is in March 2011, so a current verifier rejects that token. The tool reports an expired exp for the same reason.

What the checks look for

Check Why it matters
Self-check The signature must verify with the matching key. If it does not, the token is unusable
exp in the past A verifier must reject a token at or after exp (RFC 7519, section 4.1.4)
nbf after exp No moment exists when the token is valid
Time in milliseconds A value above 100,000,000,000 is almost certainly milliseconds; NumericDate counts seconds
Missing exp, iss, aud or sub A token without exp never expires; without aud any service that trusts the key might accept it
aud as a string or an array Both are legal for one audience (RFC 7519, section 4.1.3), but a verifier may expect an array
Secret too short Below the RFC 7518 minimum for the algorithm

Make a token for an AI agent

An AI agent that acts for a person needs a token that names both. Fill in an AI agent credential (with an act claim) writes sub as the person and act.sub as the agent.

RFC 8693, section 4.1 defines the act (actor) claim as a way to express that delegation has occurred and to identify the party to whom authority was delegated.

The preset uses a short lifetime of 5 minutes, a narrow scope and a specific aud, because an agent token is a bearer credential.

Common mistakes

  • A secret shorter than the hash output. A library may reject it, and it weakens the signature. Use at least 32 bytes for HS256.
  • Milliseconds in exp. JavaScript’s Date.now() returns milliseconds. Divide by 1,000.
  • Trusting the header to pick the algorithm. A verifier must decide which algorithms it accepts, not read alg from the token.
  • Putting secrets in claims. The payload is only encoded, not encrypted. Anyone can read it.
  • A long lifetime. A stolen token works until exp. Keep access tokens short.

Questions people ask

How do I generate a JWT?
Choose an algorithm, write the claims as JSON, and sign them with a secret or a private key. A generator encodes the header and payload as base64url, joins them with a dot, signs that string and appends the signature. Use the tool above, or a JWT library in your own code.
Who generates the JWT token?
The issuer generates it, usually an identity provider or an authorization server, after it signs a person or a service in. The application or API then verifies the signature with the issuer’s key. Applications should not mint their own sign-in tokens unless they are the issuer.
Can a JWT never expire?
Yes. The exp claim is optional in RFC 7519, so a token without it never expires. That is a risk, because a stolen token stays valid forever and cannot be recalled without extra infrastructure. Set a short lifetime for access tokens and refresh them when needed.
What exactly is a JWT?
A JWT (JSON Web Token) is a compact, URL-safe way to carry claims between two parties. It has three base64url parts: a header, a payload of claims and a signature. The signature lets a receiver check who issued the token and that nobody changed the claims.

Where to go next

Sources, all read 2026-10-27: RFC 7515, JSON Web Signature (section 7.1 and Appendix A); RFC 7518, JSON Web Algorithms (sections 3.2 to 3.5); RFC 7519, JSON Web Token (sections 2 and 4.1); RFC 8693, OAuth 2.0 Token Exchange; RFC 8725, JWT Best Current Practices.