How to use it
- 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.
- Choose the Algorithm and type the Secret. Choose Base64 under Secret encoding if the secret is written in Base64.
- Copy the Token. It has three parts separated by dots: the header, the payload and the signature.
- 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
- RFC 7519: JSON Web Token (JWT)
- RFC 7515: JSON Web Signature (JWS), appendix A.1 test vector
- RFC 7518: JSON Web Algorithms (JWA), section 3.2
- RFC 8725: JSON Web Token Best Current Practices
Figures and text last checked on Tuesday, November 10, 2026.