Here's how to create and sign a JWT token in four moves: choose a signing algorithm, build the header and payload, supply the signing key, and sign to produce a header.payload.signature string. The SnipKit JWT Encoder does all four steps client-side in your browser, so nothing you type ever leaves your machine.
A quick recap: a JWT (JSON Web Token) is a compact, signed way to pass claims — like a user ID or an expiry time — between two parties. If you need the full breakdown of header, payload, and signature structure, read JWT tokens explained first. The steps below focus on the signing part — turning a set of claims into a token a server can trust.
What signing a JWT actually does
Signing a JWT computes a cryptographic signature over the encoded header and payload combined. A JWT is three dot-separated, base64url-encoded parts — header, payload, and signature — and the signature covers the encoded header and payload together, per the jwt.io introduction. Change one character in the payload — bump a user role from "user" to "admin," for example — and the signature no longer matches. Any server verifying the token rejects it instantly.
Signing exists for exactly this reason. The signature doesn't hide the claims — the claims are just base64, not encrypted, as you can confirm in Base64 Encode/Decode. Signing instead proves the claims haven't been tampered with since they were issued.
Step by step: create and sign a JWT token
Here's how to build and sign one from scratch, using the JWT Encoder:
- Choose a signing algorithm. Pick HS256 if you're using one shared secret between issuer and verifier, or RS256 if you want separate private/public keys. Select this first in the JWT Encoder — it changes what key field you'll fill in next.
- Build the header and payload. The header records the algorithm and token type; the payload holds your claims (
sub,exp,role, whatever your app needs). Enter these as JSON in the JWT Encoder's payload editor. - Provide the signing key. For HS256, paste a strong random secret. For RS256, paste your PEM-formatted private key.
- Sign and copy the token. The JWT Encoder generates the token immediately as you edit — copy the three-part string, which looks like
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTYiLCJleHAiOjE3MjM0NTY3ODl9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c. - Verify it. Paste the token into the JWT Decoder to confirm the header, payload, and signature all check out before you ship it.
HS256 vs RS256: which signing algorithm should you pick
HS256 uses one shared secret to both sign and verify — it's HMAC-SHA256 under the hood, the same secret does both jobs. The shared secret makes HS256 fast to set up, but anyone who can verify a token can also forge one, because they hold the same key. You can generate the underlying HMAC yourself with the HMAC Generator to see how the signature math works.
RS256 uses a private key to sign and a separate public key to verify. The asymmetry means you can hand the public key to any number of services — mobile apps, third-party APIs, microservices — without giving them the power to mint new tokens.
Use HS256 when: one backend issues and verifies its own tokens (monolith, single API). Use RS256 when: multiple independent services need to verify tokens but shouldn't be able to create them (microservices, OAuth-style flows, public APIs).
Which claims to include (and always set an expiry)
RFC 7519, the JWT specification, defines a small set of registered claims worth using (see RFC 7519). The common ones are iss (issuer), sub (subject — usually the user ID), aud (audience), exp (expiration time), iat (issued-at time), nbf (not-before time), and jti (a unique token ID for revocation lists).
Of these, exp matters most. Always set a short expiry — minutes to hours for access tokens, not days. A stolen token with no expiry is valid forever; one with a 15-minute exp limits the damage window automatically.
How to sign JWTs safely
Signing a token correctly is only half the job — verifying it correctly matters just as much. The OWASP JSON Web Token Cheat Sheet recommends validating the signature on every incoming token before trusting any claim inside it, and explicitly rejecting tokens that declare "alg": "none" (see OWASP JWT Cheat Sheet). Keep signing keys — HS256 secrets and RS256 private keys alike — out of source control and client-side code. And never paste production secrets into any online tool, including this one; use test keys when experimenting with the JWT Encoder.
FAQ
How do I sign a JWT with a secret key (HS256)? Enter your claims as JSON in the JWT Encoder, select HS256, and paste your secret into the key field — the tool signs the token automatically and shows the three-part result you can copy.
What is the difference between HS256 and RS256? HS256 uses one shared secret for both signing and verifying, while RS256 uses a private key to sign and a public key to verify, letting you distribute verification power without distributing signing power.
Can I create a JWT without signing it (alg: none)?
Technically yes, but you shouldn't — the none algorithm produces a token with no signature, and OWASP specifically calls out rejecting alg: none tokens as a required server-side check, since anyone could forge one.
Sign your token now
You now have everything needed to create and sign a JWT token: pick HS256 or RS256, set your claims with a short exp, and sign. Head to the JWT Encoder to build and sign your token in the browser, then verify the result instantly with the JWT Decoder.