JWT Decoder reads an existing token and shows its contents. JWT Builder creates a new token from scratch β you define the payload (claims) and sign it with your secret key to produce a valid JWT.
This tool supports HS256 (HMAC-SHA256), HS384 (HMAC-SHA384), and HS512 (HMAC-SHA512). These are symmetric algorithms that use the same secret key to sign and verify.
This tool is ideal for development and testing. For production, sign JWTs server-side to keep your secret key private. Signing in the browser exposes the secret to anyone who can inspect your JavaScript.
Standard claims: sub (subject/user ID), iat (issued at β Unix timestamp), exp (expiration β Unix timestamp), iss (issuer), aud (audience). Custom claims can be any JSON key-value pair.
HS256 (HMAC-SHA256) uses a single shared secret β the same key signs and verifies. RS256 uses an RSA key pair β the private key signs and the public key verifies. RS256 is preferred when multiple services need to verify tokens without holding the signing key.
JWT payloads are Base64URL-encoded, not encrypted. Anyone who has the token can decode the payload and read its contents without the secret key. Never include passwords, credit card numbers, or private personal data in a JWT payload.
JWTs are stateless by design β there is no built-in revocation. Common strategies: maintain a server-side blocklist of revoked token JTI (JWT ID) values, use very short expiry times with refresh tokens, or switch to opaque session tokens if revocation is critical to your use case.
Building JWTs manually is essential for testing authentication flows, debugging token issues, and understanding how your auth system works under the hood. This tool signs real JWTs using HMAC-SHA algorithms β the same tokens your server would accept.
Select an algorithm
Choose HS256, HS384, or HS512 depending on your server's configuration. HS256 is the most common. The algorithm is embedded in the JWT header and must match what your server expects.
Edit the payload JSON
Modify the payload claims directly. Common claims: sub (subject/user ID), exp (expiration as Unix timestamp), iat (issued at), iss (issuer). Add any custom claims your application requires.
Enter your secret key
Type the HMAC secret key your server uses for verification. This is kept in browser memory only β it is never transmitted anywhere.
Sign and inspect the token
Click 'Build & Sign JWT' to generate the signed token. The tool shows the complete token and a breakdown of its three parts: header, payload, and signature.
Test authentication endpoints
Generate tokens with specific claims (user IDs, roles, scopes) to test how your API handles different token types β admin tokens, expired tokens, tokens with missing claims.
Debug authorization issues
Reproduce a specific authentication scenario by building a token with the exact claims from a bug report. Sign it with your test secret and use it to replicate the issue in a controlled environment.
Understand JWT structure in depth
See exactly how payload data becomes a signed token β useful for developers learning JWT for the first time or needing to explain the format to teammates.
Building and signing JWTs manually is useful when testing API authentication endpoints, constructing tokens for integration tests, or understanding how the signing process works before integrating a JWT library. This tool lets you define a custom payload, choose a signing algorithm (HS256, HS384, or HS512), and provide a secret key to produce a fully valid, signed token β all in your browser.
The resulting token is compatible with any RFC 7519-compliant JWT verification library. You can use it to simulate authenticated API requests with tools like curl or Postman, test your server's token validation logic, or verify that your application correctly rejects tokens with wrong signatures or expired claims. All signing uses the Web Crypto API (HMAC-SHA); your secret key never reaches any server.