JWT Encoder: How to Create and Sign JWT Tokens with HS256
Build and sign JWT tokens with HS256 using browser-native Web Crypto API. Set custom claims, expiry, and issuer without any server or library.
Try the free online tool
Runs entirely in your browser — no signup, no uploads.
Creating a JWT from scratch is straightforward once you understand the structure, but it requires careful handling of Base64url encoding, JSON serialisation, and HMAC-SHA256 signing. This tool does all of that in your browser using the native Web Crypto API, so you can generate signed tokens for testing, development, and documentation without installing any libraries or running a server.
JWT encoding is useful during API development when you need to test an authenticated endpoint before your full authentication system is in place. You can create tokens with specific claims, roles, and expiry times to verify that your backend correctly validates and enforces them.
This tool uses HS256 (HMAC-SHA256) signing, the most widely supported JWT algorithm. You provide the payload claims as JSON and a secret key, and the tool produces a correctly formatted, signed JWT that any standard JWT library will accept.
How JWT Signing Works
JWT signing involves three steps. First, the header and payload JSON objects are each serialised to compact JSON strings, then Base64url-encoded separately. Second, the two encoded parts are joined with a dot: encodedHeader.encodedPayload. Third, this joined string is signed using the specified algorithm to produce the signature, which is also Base64url-encoded.
For HS256, the signature is computed as HMAC-SHA256(secret, encodedHeader + '.' + encodedPayload). The secret key is a shared string known to both the issuer and any party that validates the token. The signed token is: encodedHeader.encodedPayload.encodedSignature.
The Web Crypto API (available in all modern browsers and Node.js 15+) provides a native implementation of HMAC-SHA256. This tool uses window.crypto.subtle.sign() to perform the signing operation entirely in the browser without sending your secret key to any server.
How to Use This Tool
Creating a signed JWT with this tool is straightforward.
- 1
Enter the payload claims
Provide the payload as a JSON object. Include standard claims: sub (subject/user ID), iss (issuer), aud (audience), iat (issued at, auto-filled), exp (expiration Unix timestamp), and any custom claims.
- 2
Set the expiry
Use the expiry helper to set the token validity period (e.g., 1 hour, 24 hours, 7 days). The tool calculates the exp claim automatically from the current time.
- 3
Enter the secret key
Provide the HMAC-SHA256 signing secret. For testing, use any string. For security, use a randomly generated secret of at least 256 bits (32 bytes).
- 4
Click Sign
The tool generates the header, encodes the payload, signs the token with Web Crypto, and assembles the complete JWT.
- 5
Copy the JWT
Copy the generated token and use it in your API test, curl command, or application code.
Common Use Cases
JWT encoding is primarily useful during development and testing.
- Generating test tokens with specific claims to verify that API endpoints enforce authorisation rules correctly.
- Creating tokens with specific roles or permissions to test access control logic without using the full auth flow.
- Generating expired tokens to test that your backend correctly rejects them with a 401 response.
- Creating tokens for different users (by varying the sub claim) to test multi-tenant data isolation.
- Generating tokens with future iat or nbf claims to test not-yet-valid token handling.
- Producing tokens for Postman environments or API documentation examples.
Security Considerations
- Never use this tool or any client-side tool to sign tokens in production; signing must happen server-side with a securely stored secret.
- Use secrets of at least 256 bits (32 bytes) for HS256 to ensure adequate security; short secrets are vulnerable to brute-force attacks.
- Prefer RS256 or ES256 in production systems where multiple services validate tokens; asymmetric algorithms do not require sharing the private key.
- Always set a reasonable exp claim; tokens without expiry are valid forever and cannot be revoked without maintaining a blocklist.
- Rotate signing secrets regularly and implement a key rotation strategy using the kid claim to avoid downtime during rotation.
Standard JWT Claims Reference
Understanding the standard registered claims helps you build well-formed tokens. The iss (issuer) claim identifies the service that created the token; validators use it to reject tokens from unexpected sources. The sub (subject) claim identifies the user or entity the token is about; it is typically a user ID.
The aud (audience) claim identifies the intended recipient; a service should reject tokens not addressed to it. The exp (expiration) claim is a Unix timestamp after which the token must not be accepted. The iat (issued at) claim records when the token was created. The nbf (not before) claim specifies the earliest time the token may be used.
Custom claims can be anything your application needs: roles, permissions, tenant ID, feature flags, or any other relevant data. Avoid storing large amounts of data in JWTs because the token must be sent with every request.
Frequently Asked Questions
Can I use this tool to create tokens for production use?
No. This tool is for development and testing only. In production, tokens must be signed server-side by a trusted authentication service with a properly stored secret. Client-side signing means the secret is visible to anyone who inspects the JavaScript, completely defeating the security model.
What is the minimum recommended secret key length for HS256?
RFC 7518 recommends that HMAC keys be at least as long as the hash output. For HS256 (SHA-256), that means at least 256 bits (32 bytes). Use a cryptographically random generator, not a password or human-readable string, to generate the secret.
Why does the iat claim get set automatically?
The iat (issued at) claim records the creation time of the token in Unix timestamp format. Setting it automatically ensures the timestamp is accurate and prevents forgetting to include it. Some validators use iat for clock skew detection and token freshness checks.
What is the difference between HS256, RS256, and ES256?
HS256 uses a shared secret for both signing and verification — simpler but requires sharing the secret. RS256 uses an RSA private key to sign and a public key to verify — better for distributed systems. ES256 uses elliptic curve cryptography with smaller key sizes than RSA for equivalent security. For most production systems with multiple token consumers, RS256 or ES256 is preferred.
Can I decode a token I created with this tool to verify it?
Yes. Copy the generated JWT and paste it into this site's JWT Decoder tool. It will display the header and payload you entered and confirm the token structure. For signature verification, use a JWT library in your backend or a trusted verification tool that accepts the same secret.
What happens if I omit the exp claim?
A JWT without an exp claim has no built-in expiry and is valid indefinitely. Most security-conscious JWT validators reject tokens without an exp claim or treat them as invalid. You should always set a reasonable expiry time to limit the window of exposure if a token is compromised.
How is Base64url different from standard Base64 in the context of JWTs?
Base64url replaces + with - and / with _ and omits padding (=). This makes the encoded string safe to use in URL path segments and query parameters without percent-encoding. JWTs use Base64url for all three parts (header, payload, signature) so that the entire token can appear in HTTP headers and URLs without modification.
Ready to use this tool?
Free, instant, no account required. Runs entirely in your browser.