Introduction
JSON Web Tokens (JWT) are a compact, URL-safe means of representing claims to be transferred between two parties. Defined in RFC 7519, JWTs are widely used for authentication and authorization in web applications and APIs. This tool lets you encode JWTs with HS256, HS384, or HS512 algorithms by entering a JSON payload and a secret key. All signing happens in your browser.
What this tool does
- Encodes JWT tokens from a JSON payload and a secret key using HMAC-SHA256 (HS256), HMAC-SHA384 (HS384), or HMAC-SHA512 (HS512).
- Constructs the standard three-part JWT format: header.payload.signature, each Base64URL-encoded.
- Validates that the payload is valid JSON before encoding.
- Displays the complete JWT string ready for use in Authorization headers.
- Processes all data locally in your browser with no network requests.
How this tool works
Enter a JSON object as the payload (e.g., `{"sub":"1234","name":"John","iat":1700000000}`), type a secret key, and select an algorithm. The tool constructs a JWT header with the chosen algorithm, Base64URL-encodes the header and payload, computes the HMAC signature using the secret, and concatenates all three parts with dots. The resulting JWT appears in the output field. If the payload is not valid JSON, an error message is displayed.
How JWT encoding works
A JWT consists of three parts separated by dots: `header.payload.signature`. The header specifies the token type (`JWT`) and the signing algorithm (e.g., `HS256`). The payload contains claims — statements about an entity (typically the user) and additional metadata. Standard claims include `iss` (issuer), `sub` (subject), `aud` (audience), `exp` (expiration time), `iat` (issued at), and `nbf` (not before). Both header and payload are serialized as JSON and Base64URL-encoded (using URL-safe characters, no padding). The signature is computed by taking the Base64URL-encoded header and payload, joining them with a dot, and signing the result with the secret key using the specified algorithm. For HS256, this is HMAC-SHA256. The signature ensures that the token has not been tampered with. JWTs are commonly used in bearer authentication: the client sends the JWT in the `Authorization: Bearer
How to use this tool
- Enter a JSON object as the payload in the payload field. Include standard claims like `sub`, `iat`, and `exp`.
- Enter a secret key in the secret field. This key is used to sign the token.
- Select the signing algorithm: HS256, HS384, or HS512.
- The JWT appears in the output field. Copy it for use in your application.
- If the payload is not valid JSON, fix the syntax and the JWT will regenerate.
Real-world examples
Creating a simple authentication token
Payload: `{"sub":"user123","name":"Alice","role":"admin","iat":1700000000}`. Secret: `mysecret`. Algorithm: HS256. Output: `eyJhbGciOiJIUzI1NiJ9.eyJzdWIi...` (three Base64URL-encoded parts joined by dots).
Token with expiration
Payload: `{"sub":"user456","exp":1700100000}`. The `exp` claim specifies when the token expires (Unix timestamp). Servers reject tokens after this time.
Using HS512 for stronger signatures
Select HS512 to use HMAC-SHA512, which produces a 512-bit signature. This provides stronger security than HS256 but results in a longer token string.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| JWT (HS256) | O(n) HMAC computation | Stateless API authentication, single-page apps |
| JWT (RS256) | O(n) RSA signature | Microservices, third-party verification |
| Session cookies | O(1) database lookup | Server-rendered apps, immediate revocation |
| OAuth 2.0 tokens | Varies by grant type | Third-party authorization, delegated access |
Limitations or considerations
This tool only supports symmetric algorithms (HS256, HS384, HS512) where the same secret is used for signing and verification. Asymmetric algorithms (RS256, ES256) require public/private key pairs and are not supported. The secret is handled in plaintext in your browser; never use production secrets in a web-based tool. JWTs are not encrypted — the payload is Base64URL-encoded, not encrypted. Anyone who intercepts the token can read the payload. For sensitive data, use encrypted tokens (JWE) or keep sensitive data server-side. JWTs cannot be revoked without additional infrastructure (blacklists, short expiration times).
Frequently asked questions
Are JWT payloads encrypted?
No. JWT payloads are Base64URL-encoded, not encrypted. Anyone who has the token can decode and read the payload. The signature only ensures integrity (the token has not been modified), not confidentiality. For encrypted tokens, use JWE (JSON Web Encryption).
What is the difference between HS256 and RS256?
HS256 uses a shared secret for both signing and verification (symmetric). RS256 uses a private key to sign and a public key to verify (asymmetric). RS256 is preferred in microservice architectures where the verifying party should not have the signing key.
How long should my secret be?
For HS256, use a secret of at least 256 bits (32 bytes). For HS512, use at least 512 bits (64 bytes). Use a cryptographically random string generator (like the Random String tool on this site) to create strong secrets.
Can I use this tool with my production secret?
No. Never enter production secrets in any web-based tool. Use this tool for development, testing, and learning only. In production, generate and sign JWTs on your server.
Conclusion
The JWT encoder is a development and testing tool for creating signed JSON Web Tokens with HMAC algorithms. It is useful for testing API authentication flows, debugging JWT-based systems, and learning how JWTs are constructed. For production use, sign tokens on your server and never expose your secret key to the browser. Pair this tool with the JWT Decoder on this site to inspect tokens.