JWT Encoder
Create and sign JSON Web Tokens with a custom payload. Uses the browser's Web Crypto API — your secret key never leaves your device.
About the JWT Encoder
This tool creates and signs JSON Web Tokens (JWTs) using HMAC-based symmetric algorithms: HS256 (HMAC-SHA256), HS384 (HMAC-SHA384), and HS512 (HMAC-SHA512). Enter a JSON payload, a secret key, and click Generate to produce a signed, production-ready JWT. The generated token is color-coded into its three dot-separated parts — header, payload, and signature — for easy inspection.
JWTs are used extensively in authentication systems. After a successful login, a server issues a signed JWT to the client; the client includes it in subsequent requests (typically as a Bearer token in the Authorization header). The server verifies the signature using the shared secret — if it matches, the token is authentic and the claims (like user ID and role) can be trusted. Common payload claims include sub (subject/user ID), iat (issued at), exp (expiration), and iss (issuer).
All signing runs locally using the browser's native Web Crypto API (crypto.subtle.sign). Your secret key is never transmitted. To decode and inspect an existing JWT, use the companion JWT Decoder tool.
Frequently Asked Questions
What is the difference between HS256, HS384, and HS512?
All three use HMAC (Hash-based Message Authentication Code) with a shared secret. The number indicates the SHA hash length: 256, 384, or 512 bits. HS256 is the most widely used and is sufficient for most applications. HS384 and HS512 produce longer signatures and are used when higher security margins are required. The choice is often dictated by the library or API you are integrating with.
What is the difference between HS256 and RS256?
HS256 uses a single shared secret for both signing and verification — simpler but requires all verifiers to know the secret. RS256 uses an asymmetric key pair: the private key signs the token, and the public key verifies it. RS256 is preferred for distributed systems where tokens are verified by multiple services that should not have access to the signing key.
Should JWTs be stored in localStorage or cookies?
Cookies with HttpOnly and Secure flags are generally safer. HttpOnly prevents JavaScript from accessing the token (protecting against XSS), and Secure ensures it's only sent over HTTPS. localStorage is accessible to all JavaScript on the page, making it vulnerable to XSS attacks that steal the token.
How do I set a token expiration time?
Add an exp claim to the payload with a Unix timestamp value (seconds since epoch). For example, "exp": 1700000000. Servers should always validate the exp claim and reject expired tokens. The JWT Encoder preset examples include iat (issued at) and exp (1 hour from now) by default.