How to use the JWT Encoder
Create a signed JWT in three steps:
1
Edit the JSON payload
Modify the payload JSON in the editor. Use the preset buttons (User Auth, API Access, Refresh Token) for common patterns, or use 'Add iat + exp' to inject fresh timestamps into your existing payload.
2
Set the algorithm and secret
Choose HS256, HS384, or HS512. Enter a secret key in the signing secret field. Toggle the eye icon to show or hide the secret.
3
Sign and copy
Click 'Sign & Encode JWT'. The signed token appears colour-coded in three sections. Copy the full token to use in API requests, Postman, or curl.
When to use this tool
Use the JWT encoder to create signed tokens for testing, development, and learning:
- →Generating test JWT tokens for local development when an authentication server is not available or convenient to use
- →Creating signed tokens to test API endpoint authorisation logic without setting up a full auth flow
- →Building JWT tokens with specific claims (roles, scopes, custom fields) to test how your backend handles different claim combinations
- →Generating expired or future-dated tokens to test token validation edge cases in your application
- →Learning how JWT signing works by experimenting with different payloads, secrets, and algorithms
- →Creating tokens for Postman, curl, or other HTTP client environments when a real auth server is not accessible
Frequently asked questions
Q:What algorithms are supported?
Three HMAC-based algorithms are supported: HS256 (HMAC with SHA-256), HS384 (HMAC with SHA-384), and HS512 (HMAC with SHA-512). All use a shared secret key for both signing and verification. HS256 is the most widely used and the default in most JWT libraries. HS384 and HS512 produce longer, stronger signatures but are rarely needed for typical web authentication use cases. Asymmetric algorithms (RS256, ES256) require a private key and certificate and are not supported by this tool.
Q:How long should the secret key be?
For HS256, the HMAC-SHA-256 block size is 64 bytes. RFC 7518 recommends using a key with at least as many bits as the hash output — 256 bits (32 bytes) for HS256, 384 bits (48 bytes) for HS384, 512 bits (64 bytes) for HS512. Short secrets are vulnerable to brute-force attacks. A good minimum is a randomly generated string of at least 32 characters. Never use human-memorable phrases, dictionary words, or the placeholder 'your-256-bit-secret' in production.
Q:Is it safe to use this tool with real secrets?
All signing happens in your browser using the Web Crypto API — the secret is never transmitted to any server. However, standard browser security caveats apply: avoid using production secrets in any browser-based tool, as the secret could be exposed through browser extensions, XSS attacks on the page, or screenshots. For production JWT signing, always use server-side code with secrets stored in environment variables or a secrets manager, never in client-side JavaScript.
Q:What JWT claims should I include in the payload?
At minimum, include iat (Issued At — current Unix timestamp) and exp (Expiration — future Unix timestamp) so tokens can be validated for timeliness. Include sub (Subject) with the user's unique identifier so the token identifies who it belongs to. Add iss (Issuer) to identify your application, and aud (Audience) if the token is intended for a specific service. Beyond standard claims, add whatever custom claims your application needs — roles, permissions, user metadata — but keep the payload small since it is included in every request.
Q:What is the difference between HS256 and RS256?
HS256 (HMAC-SHA256) is a symmetric algorithm — the same secret key is used to both sign and verify the token. This means any service that can verify a token can also create one. RS256 (RSA-SHA256) is an asymmetric algorithm — a private key signs the token and a corresponding public key verifies it. Services can verify tokens without being able to create them, which is more secure in multi-service architectures. This tool supports HS256/384/512 only. For RS256/ES256, use a server-side JWT library.
Q:Why does the payload editor validate JSON in real time?
The Sign button is disabled whenever the payload contains invalid JSON, preventing you from signing a malformed token. The editor shows a ✓ Valid JSON badge when the JSON parses correctly and a ✗ Invalid JSON badge with the exact parse error when it does not. This catches common issues like trailing commas, missing quotes, or mismatched brackets before you attempt to sign. The JWT header ({"alg": "HS256", "typ": "JWT"}) is always generated correctly by the tool and does not need to be edited.