JWT Builder
Create and sign JSON Web Tokens
Algorithm & Options
Header
Payload
Secret Key
Security Note: Never enter production secrets here. This tool runs entirely in your browser, but secrets should remain confidential.
Ready to Build
Configure header, payload, and secret key, then click Build & Sign Token
Understanding JWT (JSON Web Tokens)
JSON Web Tokens (JWTs) are a standard method for securely transmitting claims between two parties. A JWT consists of three parts separated by dots: a header (algorithm and type), a payload (claims and user data), and a signature (cryptographic proof of authenticity). Unlike session-based authentication where the server stores session state, JWTs are stateless—the server validates the token signature to confirm it is legitimate without looking up session data. This makes JWTs ideal for distributed systems, microservices, and mobile applications where session storage is not practical. When a user logs in, they receive a JWT containing their user ID, role, and other claims. This token is stored on the client and sent with every API request in the Authorization header, allowing the server to verify the user identity without maintaining server-side session storage.
The signature is what makes JWTs secure. The server signs the token using a secret key (for HS256) or private key (for RS256), creating a cryptographic hash of the header and payload. If anyone modifies the token data, the signature becomes invalid, so the server rejects tampered tokens. However, the token payload is not encrypted—it is only Base64-encoded, so sensitive data should never be stored directly in a JWT. This tool helps you understand JWT structure by building tokens with custom payloads and visualizing how the three parts combine.
Common Use Cases
- API Authentication Testing: Create mock JWTs with specific user roles and claims to test protected API endpoints without needing a real authentication server.
- Development & Debugging: Generate tokens with custom expiry times and payloads to debug authentication logic and test error scenarios like expired or invalid tokens.
- Token Structure Learning: Understand JWT anatomy by building tokens and examining how header, payload, and signature interact.
- Integration Testing: Create test tokens for automated test suites that need to authenticate against JWT-secured services.
- Microservice Development: Generate service-to-service authentication tokens for testing inter-service communication in distributed systems.
How to Use This Tool
- Select Algorithm: Choose a signing algorithm (HS256, HS384, HS512 for symmetric, RS256 for asymmetric). HS256 is the most common for development.
- Configure Header: Edit the header JSON. Default includes algorithm and token type (JWT). You can add custom fields if needed.
- Build Payload: Edit the payload JSON with standard claims (sub, iss, aud, exp, iat, jti) and custom claims for your user data. Click "+ jti" to add a unique token ID.
- Set Expiry: Toggle "Add exp" and set expiration time in minutes. The token will include an exp claim with the calculated Unix timestamp.
- Enter Secret Key: Provide your signing secret. For development, use any string. For production, use a strong, randomly-generated key.
- Build & Sign: Click "Build & Sign Token" to generate the JWT. The output shows the three parts with color-coded syntax highlighting.
- Copy & Use: Copy the token and use it in API requests by adding it to the Authorization header: Authorization: Bearer {token}.
Features
Standard Claims
iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), jti (JWT ID). These are optional but provide important metadata.
Algorithm Selection
HS256/384/512 use a shared secret, making them simpler for single-server apps. RS256 uses asymmetric keys, ideal for distributed systems.
Expiration Control
Set custom expiry times to test token refresh logic and expired token scenarios. Tokens are valid until the exp claim Unix timestamp.
Custom Claims
Add any JSON fields to the payload for application-specific data (user ID, roles, permissions). These become accessible after token validation.
Frequently Asked Questions
Is it safe to use tokens generated here in production?
No. This tool is for development, testing, and learning only. Production tokens must be generated by your authentication server using secure key management. Never expose your production signing keys or tokens online.
What is the difference between HS256 and RS256?
HS256 uses a single shared secret (symmetric) and is simpler for single-server applications. RS256 uses a private key to sign and a public key to verify (asymmetric), making it ideal for distributed systems where multiple services need to validate tokens without sharing secrets.
How do I set a token expiry?
Enable the "Add exp" checkbox and enter the number of minutes the token should be valid. The tool calculates the Unix timestamp (current time + minutes) and includes it in the exp claim.
What are standard JWT claims?
Standard claims include: sub (subject/user ID), iss (issuer/authentication server), aud (audience/API), exp (expiration Unix timestamp), iat (issued-at Unix timestamp), and jti (unique token ID). These are optional but widely recognized and used by JWT libraries.