JWT Parser / Generator
Decode any JWT's three-part structure, verify HMAC signatures, and generate signed tokens with custom payloads
JWT Input
Paste your JWT token to decode and inspect
Example Payloads
Click a payload to load it into the generator
Algorithm Reference
| Algorithm | Type | Key | Security |
|---|---|---|---|
HS256 | HMAC Symmetric | Shared Secret | Standard |
HS384 | HMAC Symmetric | Shared Secret | Standard |
HS512 | HMAC Symmetric | Shared Secret | Strong |
RS256 | RSA Asymmetric | Private/Public Key | Strong |
ES256 | ECDSA Asymmetric | EC Key Pair | Very Strong |
Standard JWT Claims
| Claim | Type | Description |
|---|---|---|
sub | string | Subject (user ID) |
iss | string | Issuer |
aud | string | Audience |
exp | number | Expiration time (Unix timestamp) |
iat | number | Issued at (Unix timestamp) |
nbf | number | Not before (Unix timestamp) |
jti | string | JWT unique identifier |
About JWT Parser & Generator
JWT (JSON Web Token) is the most widely used stateless authentication standard in modern web applications, adopted by OAuth 2.0, OpenID Connect, and other major authorization protocols. A JWT consists of three Base64Url-encoded JSON segments — Header, Payload, and Signature — joined by dots.
This tool implements full JWT decode and generation entirely in-browser, supporting HS256/HS384/HS512 HMAC algorithms via the Web Crypto API. Use it to debug API authentication, verify token validity, or quickly generate test tokens — all operations stay local, keeping your secrets safe.
How to Use
Decode mode: Paste a JWT token into the input area. The tool auto-decodes Header and Payload from Base64Url, parses standard claims (exp/iat/nbf/sub/iss/aud/jti), and displays them in readable format. Enter the signing secret and click "Verify Signature" to validate token integrity via HMAC-SHA256/384/512.
Generate mode: Write your payload JSON in the editor (use the quick-set buttons for iat/exp timestamps), select HS256/HS384/HS512 algorithm, enter your HMAC secret, and click Generate to produce a signed three-part JWT token.
Security Notes
- All cryptographic operations run locally in your browser via the Web Crypto API. Tokens and secrets are never transmitted over the network to any server.
- JWT Payload is only Base64Url-encoded, not encrypted — never store passwords, credit card numbers, or other sensitive data in the Payload. For encrypted transport, use JWE (JSON Web Encryption).
- For production, prefer RS256 or ES256 asymmetric algorithms. Symmetric algorithms (HS256) require sharing the secret between signer and verifier, increasing the key exposure surface.
Production Scenarios
Debugging API Gateway Auth Failures
When users report 401 errors, copy the JWT from the Authorization header in the browser's DevTools Network panel. Paste it into the decoder to instantly check whether the token has expired, whether the issuer is correct, and whether the algorithm matches. Combine with signature verification to rule out MITM tampering.
Verifying Tokens from Third-Party IdPs
JWTs issued by Auth0, Keycloak, Firebase Auth, and other identity providers typically use RS256 signing. This tool's HS256/384/512 verification is suitable for self-checking internal service tokens. For RS256 tokens, you can still decode Header and Payload to inspect claims — signature verification against RS256 requires the IdP's JWKS public key endpoint.
Generating Test Tokens in CI/CD Pipelines
Integration tests often need a valid JWT to simulate authenticated users. Use the Generate mode to create a test-user payload with an appropriate expiry (e.g. 1 hour), sign it with a test secret, and inject it as a CI environment variable. Never hardcode production secrets into CI configurations.
Debugging Microservice JWT Trust
In microservice architectures, the Gateway issues a JWT that downstream services must validate. When debugging, copy the Gateway-issued token into the decoder to verify that the aud claim correctly targets the intended service, and confirm the exp covers the maximum inter-service call latency.
Troubleshooting Token Refresh Failures
When the Refresh Token rotation mechanism malfunctions (e.g. users are unexpectedly logged out), paste the Refresh Token into the decoder to inspect exp and iat fields. Confirm the token validity window and issuance time match expectations, and rule out clock skew issues between services.
Common Pitfalls
Confusing Base64 with Base64Url
JWT uses Base64Url encoding (- replaces +, _ replaces /, trailing = stripped), not standard Base64. If your backend manually constructs JWTs with standard Base64, the token will be corrupted in transit. This tool auto-handles both encoding variants — paste any format and it will decode correctly.
Skipping Algorithm Validation — The "none" Attack
The JWT spec allows alg: "none" for unsigned tokens. If your server-side JWT library doesn't enforce an algorithm allowlist, an attacker can send an alg: "none" token to bypass signature verification entirely. In production, always whitelist accepted algorithms (e.g. only RS256) and reject both "none" and algorithm confusion attacks (e.g. HS256→RS256).
Skipping aud and iss Validation
Verifying only the signature and expiry is not enough. Always validate aud (audience) to ensure the token was issued for your service, and iss (issuer) to ensure it came from a trusted source. Skipping these checks enables cross-service token abuse — a token issued for the logging service should never be accepted by the database service.
Insufficient Key Length
HS256 requires a key of at least 256 bits (32 bytes), HS384 requires 384 bits (48 bytes), and HS512 requires 512 bits (64 bytes). Using a short key like "secret" drastically weakens the signature. Always use randomly generated keys and inject them via environment variables or a secrets management service (Vault/KMS).
Deep Dive: Symmetric vs Asymmetric Algorithm Selection
Symmetric algorithms (HS256/HS384/HS512) use the same key for both signing and verification. Simple architecture, well-suited for monoliths or internal tools. The downside: the key must be shared with every service that needs to verify tokens — the key exposure surface grows linearly with service count. In a microservice architecture, compromising any single key-holding service compromises the entire token system.
Asymmetric algorithms (RS256/RS384/RS512/ES256/ES384/ES512) use a private key for signing and a public key for verification. The auth service holds the private key exclusively; downstream services only hold the public key. Even if a downstream service is compromised, tokens cannot be forged. RS256 (RSA-based) offers the best compatibility but produces longer signatures (~342 bytes). ES256 (ECDSA P-256) produces signatures of only ~64 bytes with equivalent security and smaller keys, making it ideal for mobile and bandwidth-sensitive scenarios.
Decision guidance: Use HS256 for single-service or internal-tool scenarios for maximum simplicity. For multi-service/microservice architectures, prefer RS256 or ES256. If integrating with third-party IdPs (Auth0/Okta), they typically mandate RS256. For key management: symmetric secrets can live in environment variables or Vault; asymmetric private keys must be protected by HSM or cloud KMS, with public keys distributed via a JWKS endpoint.