JWT Builder / Encoder
Build and sign JSON Web Tokens with HS256, HS384, or HS512. All processing happens in your browser.
Security reminder: JWTs are encoded, not encrypted — anyone with the token can read the payload. Never include passwords or secrets in the payload. Always verify tokens server-side.
What is a JSON Web Token?
A JSON Web Token (JWT) is a compact, self-contained way to securely transmit information between parties as a JSON object. The information is verified and trusted because it is digitally signed. JWTs are widely used for authentication and information exchange in web applications, APIs, and microservices.
A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. The signature is computed over the header and payload using a secret key, which allows the receiver to verify that the token has not been tampered with.
JWT Structure
// Header (base64url-encoded)
{
"alg": "HS256",
"typ": "JWT"
}
// Payload (base64url-encoded)
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
// Signature
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)Standard JWT Claims
{
// Registered claims (standard, optional but recommended)
"iss": "https://auth.example.com", // issuer
"sub": "user_123", // subject
"aud": "https://api.example.com", // audience
"exp": 1716239022, // expiration (Unix timestamp)
"nbf": 1716235422, // not before
"iat": 1716235422, // issued at
"jti": "unique-token-id", // JWT ID
// Custom claims — your application data
"role": "admin",
"email": "user@example.com"
}The payload can contain any JSON-serializable data, but avoid storing sensitive data such as passwords, credit card numbers, or personally identifiable information (PII). The payload is only Base64URL-encoded — anyone who obtains the token can decode and read it.
HMAC Algorithms Compared
| Algorithm | Hash Function | Key Length | Output Size | Use Case |
|---|---|---|---|---|
| HS256 | SHA-256 | 32+ bytes recommended | 256 bits (32 bytes) | General purpose, most common |
| HS384 | SHA-384 | 48+ bytes recommended | 384 bits (48 bytes) | Higher security, moderate overhead |
| HS512 | SHA-512 | 64+ bytes recommended | 512 bits (64 bytes) | Maximum security, largest tokens |
Security Warnings
- Never put secrets in the payload. The payload is only encoded, not encrypted. Anyone with the token can decode and read the payload in plain text.
- Always verify server-side. Client-side validation of JWTs is not sufficient. Always verify the signature and claims (exp, iss, aud) on the server.
- Use a strong secret. For HS256, use a secret of at least 256 bits (32 random bytes). Weak secrets can be brute-forced.
- Set expiration (exp). Tokens without expiration remain valid forever. Use short-lived tokens and refresh token rotation.
- Use HTTPS only. Transmit JWTs exclusively over TLS. Tokens intercepted over HTTP can be replayed by an attacker.
- Consider asymmetric algorithms (RS256, ES256) for public clients. With HMAC, both parties need the same secret. RSA/ECDSA allow public key distribution.
When to Use JWTs
- Stateless authentication — issue a token on login, verify on each request without a database lookup
- API authorization — pass user roles and permissions in the token payload
- Microservices — service-to-service authentication without a shared session store
- Single sign-on (SSO) — share authentication across multiple domains
When NOT to Use JWTs
- Session management — JWTs cannot be invalidated before expiration (use server-side sessions with Redis for revocable sessions)
- Storing sensitive data — payload is publicly readable; use encrypted JWTs (JWE) if you must store private claims
- Large payloads — JWTs are included in every request header; keep them small (under 4 KB)