JWT Generator
Generate JWT tokens with custom header and payload for testing.
Last updated: August 2026
Note: Signature is illustrative. For production JWTs, use a proper library with real HMAC signing.
Was this tool helpful?
What a JWT is made of
A JSON Web Token is three Base64URL-encoded parts joined by dots:header.payload.signature. The header names the signing algorithm, commonly HS256 or RS256. The payload holds claims, which are just JSON key-value pairs such assub (the subject), exp (expiry as a Unix timestamp), and iat (issued-at). The signature is computed over the first two parts with a secret or private key, and that is what lets a server trust the token later without a database lookup.
HS256 versus RS256
HS256 is symmetric: the same secret signs and verifies, so anyone who can verify can also forge. It fits a single service that keeps its own secret. RS256 is asymmetric: a private key signs and a public key verifies, so you can hand the public key to many consumers while only the issuer can mint tokens. Pick RS256 when the signer and verifier are different parties.
Example
A decoded payload before signing:
{
"sub": "user_123",
"role": "editor",
"iat": 1710000000,
"exp": 1710003600
}The resulting token has the familiar three-segment shape:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.3vJ8...FAQ
Is the payload encrypted? No. It is only encoded, so anyone can decode and read it. Never put passwords or secrets in a JWT; the signature proves integrity, not confidentiality.
What stops someone editing the claims? Changing the payload invalidates the signature, and the server rejects it on verify. That only holds if the server actually checks the signature and does not accept the none algorithm.
How do I handle expiry? Set exp to a short window and issue a separate longer-lived refresh token. The verifier must compare exp against the current time and reject anything past it.