Quick answer
A signed JWT is three Base64url parts joined by dots: header.payload.signature. The header and payload are just encoded JSON (readable by anyone), while the signature is an HMAC of those two parts computed with your secret. This tool builds and signs the token entirely in your browser using the Web Crypto API — the secret is never uploaded.
How a JWT is built
Creating a signed JWT is a three-step process, and you can watch each part update as you edit the fields above:
- Encode the header — a small JSON object naming the algorithm (
alg) and token type (typ) — with Base64url. - Encode the payload — your claims, such as
sub,name,iat, andexp— with Base64url. - Sign the string
header.payloadusing HMAC-SHA with your secret, and Base64url-encode the result. Appending it gives the finalheader.payload.signature.
Because the signature depends on every byte of the header and payload plus the secret, changing any claim invalidates the signature — which is exactly how a verifier detects tampering.
Encoding is not encryption
The single most important thing to understand about JWTs is that the payload is not secret. Anyone holding the token can Base64url-decode the middle segment and read every claim — try it in the JWT Decoder. The signature protects integrity (proof the token wasn't altered), not confidentiality. So never place passwords, API keys, or personal data you wouldn't want exposed inside a JWT payload. If you need the contents hidden, encrypt the token (JWE) or don't put the sensitive data in it at all.
Standard claims worth knowing
iss— issuer: who created the token.sub— subject: usually the user ID the token represents.aud— audience: the intended recipient/service.exp— expiry: a Unix timestamp (seconds) after which the token must be rejected.nbf— not before: a timestamp before which the token is invalid.iat— issued at: when the token was created.jti— JWT ID: a unique identifier, useful for revocation lists.
The exp, nbf, and iat claims are Unix timestamps in seconds — you can convert human dates with the Timestamp Converter. Use the quick buttons above to insert iat and exp automatically.
HS256 vs HS384 vs HS512
All three algorithms this tool supports are HMAC-based: they sign with a single shared secret that both the issuer and the verifier hold. They differ only in the underlying hash — SHA-256, SHA-384, or SHA-512 — which changes the signature length, not the fundamental security model. HS256 is by far the most widely used and is appropriate for most applications. The larger variants exist for systems that standardize on bigger hashes. The critical rule is that the signer and verifier must agree on both the algorithm and the secret; a mismatch on either makes every token fail verification. There is also a family of asymmetric algorithms (RS256, ES256) that sign with a private key and verify with a public key — useful when many parties must verify but only one may issue — which this HMAC-focused tool does not cover.
Frequently Asked Questions
Is it safe to sign a JWT online?
With this tool, yes — signing happens entirely in your browser using the Web Crypto API, and your secret is never sent anywhere. That said, treat any token you sign here as disposable and never paste a real production signing secret into any website. For production, sign tokens on your server. This tool is ideal for learning, testing, and creating tokens for your own local development.
What is the difference between encoding and signing a JWT?
Encoding is just Base64url — the header and payload are readable by anyone, so encoding provides no secrecy. Signing adds a cryptographic signature computed from the header, payload, and a secret. The signature lets a receiver verify the token wasn't tampered with, but it does not hide the contents. Never put passwords or secrets inside a JWT payload.
Which algorithm should I use — HS256, HS384, or HS512?
All three are HMAC algorithms that use a shared secret; they differ only in the SHA hash size. HS256 is the most common and is sufficient for the vast majority of use cases. HS384 and HS512 use larger hashes and longer signatures. Choose based on what your verifying service expects — they must agree on the algorithm and secret.
How do I add expiry to a JWT?
Add an exp claim to the payload — a Unix timestamp in seconds after which the token is invalid. The iat claim records when it was issued. Use the Add iat and Add exp buttons to insert them automatically (exp defaults to one hour from now), then adjust as needed.
Does this tool store or transmit my secret?
No. The secret stays in the page's memory only for the moment it signs the token, and it is never stored or sent over the network. All cryptography runs locally through the browser's built-in Web Crypto API. You can confirm this by opening your browser's network tab — signing makes no requests.