JWT Generator and Checker

Edit the header and the payload as JSON, set the times with one click and sign the token with your secret. Paste a token below to check its signature with the same secret.

Free Runs in your browser Checked Tuesday, November 10, 2026

This tool runs in your browser. What you enter is not sent to us.

How to use it

  1. Write the Header (JSON) and the Payload (JSON). Use Set iat to now, Set nbf to now or Set exp in to fill the times.
  2. Choose the Algorithm and type the Secret. Choose Base64 under Secret encoding if the secret is written in Base64.
  3. Copy the Token. It has three parts separated by dots: the header, the payload and the signature.
  4. Paste a token into Token to check to see whether its signature matches the secret above.

How a JWT is signed

A JSON Web Token (RFC 7519) is a header and a payload, each written as JSON and encoded in Base64url (RFC 7515), joined by a dot. The signature is an HMAC of those two parts, made with the secret (RFC 7518, section 3.2). The header names the algorithm in its alg field, and this page sets that field to the algorithm you choose.

The page writes each JSON object in its compact form before encoding it, so the signed bytes are the compact form of what you typed, not the text with its spaces and line breaks. Any party that checks the token works from the bytes it receives, so the token is valid either way.

signing input = BASE64URL(header) . BASE64URL(payload)
signature    = HMAC-SHA-256(secret, signing input)
               (HS384 and HS512 use HMAC-SHA-384 and HMAC-SHA-512)
token        = signing input . BASE64URL(signature)

The times in the payload

The claims iat (issued at), nbf (not before) and exp (expiration time) are NumericDates: seconds since 1 January 1970 at 00:00 UTC (RFC 7519, sections 2 and 4.1). A token is not accepted at or after exp, and not before nbf. The buttons write the time from your device's clock, so a wrong clock gives a wrong time.

What checking does and does not do

Checking recomputes the HMAC of the header and payload exactly as they were pasted, and compares it with the signature. It refuses alg none and every algorithm except HS256, HS384 and HS512, so a token cannot choose a weaker check.

It does not check what the claims mean: that iss is the issuer you expect, or that aud names your service. Your application must check those, as RFC 8725 recommends.

Worked example: HS256 with the secret your-256-bit-secret

With the header {"alg": "HS256", "typ": "JWT"}, the payload {"sub": "1234567890", "name": "Ada Lovelace", "iat": 1516239022} and the UTF-8 secret your-256-bit-secret, the page makes this token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMn0.nmm0qepYRjhNji3O-jq8Pvcr7l_me1_bomw4EJucQCU

Checking it with the same secret gives a valid signature. The token has no exp or nbf claim, so no time can make it invalid. Checking it with any other secret reports that the signature does not match.

Frequently asked questions

Is my secret sent to a server?

No. The token is signed in your browser with the browser's own SubtleCrypto. The secret is kept only while the page is open: it is not sent, stored or logged.

Why does the page say the signature matches, but my library rejects the token?

The library may check the exp or nbf times, the audience or the issuer, or it may read the secret in another encoding. Read the secret as UTF-8 or as Base64 in the same way your library does, and compare the times with a correct clock.

Why is alg none refused?

A token with alg none has no signature, so anyone can write one. A service must reject it. This page refuses it when checking, and its signing always writes an HMAC algorithm.

How long should the secret be?

At least as long as the hash output: 32 bytes for HS256, 48 for HS384 and 64 for HS512 (RFC 7518, section 3.2). The page warns when the secret is shorter.

Can this page make RS256 or ES256 tokens?

No. It signs and checks with a shared secret only, using HS256, HS384 or HS512. Tokens signed with a private RSA or ECDSA key need that key, which this page does not take.

When should I choose Base64 for the secret?

Only when the secret is written in Base64, for example the k value of a JSON Web Key. Otherwise the secret is read as UTF-8 text exactly as you typed it, spaces included.

Sources

Figures and text last checked on Tuesday, November 10, 2026.

We use necessary cookies to run the site. With your consent, Google also uses advertising cookies to show personalised ads. If you reject them, you still see ads, but they are not personalised.