What a JWT Is, In One Paragraph
A JSON Web Token is a compact, URL-safe way to encode claims about something — a user's identity, what they can access, when their session expires — plus a signature that proves the claims weren't tampered with. A JWT looks like xxx.yyy.zzz: three base64url-encoded parts separated by dots. The first part (xxx) is the header (algorithm + token type). The middle (yyy) is the payload (the claims). The last (zzz) is the HMAC or RSA signature over header+payload.
The JWT Token Generator builds and decodes JWTs. Build mode: paste a JSON payload, pick HS256/HS384/HS512, provide a secret, get a signed token. Decode mode: paste any JWT, see its header and payload (signature verification requires the secret separately). Useful for testing auth flows, building tokens by hand for API tests, or inspecting tokens you've received from a server.
How the Microapp JWT Token Generator Works
Pick mode. Build: paste your payload as JSON (the sample includes sub, iat, exp claims), pick HS256 (most common), HS384, or HS512, type a secret, click Build JWT. Decode: paste any JWT, see the decoded header and payload as formatted JSON.
HMAC signing uses the Web Crypto API. Your secret never leaves your browser — there's no server roundtrip, no logging, no analytics on what you paste. Decode is a pure base64url-decode plus JSON.parse on each segment; the signature is shown as base64url but not verified (verification requires the secret, which most JWT decoders don't ask for).
{"sub":"user_123","exp":1735689600} and secret mysecret, algorithm HS256. Output: a 3-part dotted string like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTczNTY4OTYwMH0.[signature]. Decode mode on that same string returns the original header + payload.
How JWTs Differ From Random Tokens
The Token Maker generates random unstructured tokens — opaque strings the server stores in a database. Logging in: client sends the token; server looks it up in the sessions table. Tokens have no inherent meaning; the server's database does the work.
JWTs are the opposite: self-contained. The token IS the claim. Logging in with a JWT: client sends the token; server verifies the signature locally and trusts the claims inside without looking anything up. No database lookup means JWT auth scales horizontally and works in stateless services.
Trade-off: JWTs are bigger than opaque tokens (a typical JWT is 150-500 bytes vs 32-64 for a random token). They're also harder to revoke — if you want to invalidate a JWT before its expiration, you need a server-side blocklist, which defeats some of the stateless advantage. Pick JWTs when you need self-contained auth (microservices, stateless API gateways); pick opaque tokens when you want easy revocation (consumer apps, anything where "log out everywhere" is a feature).
The HS256/HS384/HS512 Algorithms
HMAC variants of JWT signing. HS256 uses HMAC-SHA256 — by far the most common choice and what most JWT libraries default to. HS384 and HS512 use larger SHA hashes (more compute, slightly more collision resistance, no real-world security difference). Pick HS256 unless your server requires a specific one.
All three are symmetric: the same secret is used to sign and to verify. Both parties (the issuer and the verifier) must know the secret. This is fine when both parties are servers you control; it's a problem if you want a third party to verify without being able to mint new tokens.
For the third-party scenario, use asymmetric JWT signing: RS256 (RSA) or ES256 (ECDSA). The issuer keeps a private key for signing; the verifier only needs the public key. This tool generates HMAC tokens only — RS256/ES256 require a different UI for keypair upload.
Standard JWT Claims
| Claim | Meaning | Format |
|---|---|---|
sub | Subject (who the token is about) | String, usually a user ID |
iss | Issuer (who created the token) | String, usually a service URL or name |
aud | Audience (who the token is for) | String or array of strings |
exp | Expiration time | Unix timestamp (seconds since 1970) |
nbf | Not before (don't accept before this time) | Unix timestamp |
iat | Issued at | Unix timestamp |
jti | JWT ID (unique identifier for this token) | String, unique per token |
All defined in RFC 7519. Servers should always check exp at minimum; ignoring it means tokens last forever, which is a real security hole. The sample payload in the tool includes sub, iat, and exp set to one hour in the future — typical for short-lived API tokens.
Common Pitfalls
Trusting decoded JWTs without verifying. Decoding shows you the header and payload — anyone can do that, the parts are just base64. Verification (running HMAC-compare against the secret) is what proves the token wasn't forged. The decoded payload is unsigned data until you've verified the signature; treat it as untrusted input until then.
Using none as the algorithm. JWT spec includes a none algorithm meaning "no signature." This was a security catastrophe — early libraries would accept {"alg":"none"} tokens as valid. Modern libraries reject it; never enable it.
Confusing HS256 with HMAC-SHA256-on-the-secret. JWT HS256 is HMAC over base64url(header) + "." + base64url(payload) with the secret as the HMAC key — not HMAC of the secret directly. The signing function is built into JWT libraries; don't try to roll your own.
Storing JWT secrets in client code. The secret signs tokens. If the client knows the secret, the client can mint tokens claiming to be anyone. Secrets stay server-side, always. The client only ever has the token, never the secret.
Long-lived tokens with no revocation. JWT's stateless nature makes revocation hard. A token issued for 30 days is valid for 30 days regardless of what happens server-side. Use short-lived tokens (15min - 1hr) plus a refresh token mechanism, or maintain a server-side blocklist for compromised tokens.
Related Tools
For random unstructured tokens (the alternative to JWT), use the Token Maker. For HMAC computations standalone (without the JWT envelope), the SHA-256 Generator is the right tool. For Base64-url decoding (the encoding JWTs use for each segment), see the Base64 Encoder/Decoder. For TOTP one-time codes (a different kind of authentication), the OTP Generator is the right choice.