Header
Payload
Secret Key
Signed JWT
Click "Sign JWT" to generate the token…
Header
Payload
Signature
JWT Creator generates JSON Web Tokens from a header, payload, and signing secret. Select the signing algorithm (HS256, HS384, HS512, RS256, RS384, RS512, ES256), enter key-value pairs for the payload (including standard claims like iss, sub, aud, exp, iat), and get the signed JWT token ready to use in Authorization headers. It also validates the generated token and shows the decoded output.
JWT (JSON Web Token) is a compact, URL-safe token format for representing claims between parties. A JWT has three base64url-encoded parts separated by dots: header (algorithm type), payload (claims/data), and signature. The signature is computed using the secret key — only parties with the key can verify the token's authenticity. JWTs are used for: API authentication (Bearer tokens), SSO (Single Sign-On), stateless session management, and securely passing data between microservices.
Key JWT security considerations: always verify the signature before trusting claims. The 'none' algorithm (no signature) must be explicitly rejected by your verification code. Sensitive data should not be in the payload — JWTs are base64-encoded (not encrypted), so anyone can decode the payload without the secret. For sensitive payloads, use JWE (JWT Encryption). Set short expiration times (exp claim) and implement token revocation for critical systems.
Create API access token
Result: Payload: {sub:'user123', iss:'myapp.com', exp:1753580400} + HS256 → signed JWT
Service-to-service JWT
Result: Payload: {iss:'service-a', aud:'service-b', scope:'read:data', exp:+300s} → short-lived token
Debug existing token
Result: Paste existing JWT → see decoded header and payload, verify signature with your secret
What is the difference between HS256 and RS256 signing algorithms?
HS256 (HMAC-SHA256) uses a single shared secret for both signing and verification — symmetric. Both parties must know the secret. RS256 (RSA-SHA256) uses a private/public key pair — asymmetric. The private key signs the token; the public key verifies it. Use RS256 when: different services verify tokens without sharing a secret, you need to publish your verification key (JWKS endpoint), or you're implementing OAuth2/OIDC. Use HS256 for simpler internal systems where you control both signing and verification.
Are JWTs encrypted?
No — by default, JWTs are signed but not encrypted. The header and payload are only base64url-encoded, which anyone can decode. The signature prevents tampering but provides no confidentiality. Do not put sensitive information (passwords, PII, access credentials) in a standard JWT payload. If you need encrypted JWTs, use JWE (JSON Web Encryption) — this adds an encryption layer. Most JWT implementations are JWS (JSON Web Signature), not JWE.
What is the exp claim and how should I set it?
exp (expiration time) is a Unix timestamp (seconds since epoch) after which the JWT must be rejected. Set it using: Math.floor(Date.now() / 1000) + (60 * 60) for 1 hour expiry. Short-lived tokens (15 min to 1 hour) limit the damage window if a token is stolen. Use refresh tokens for maintaining sessions longer — the refresh token is kept server-side, issued new access tokens when the access token expires. Never issue tokens without expiry for production APIs.
What is the 'none' algorithm vulnerability?
Some early JWT libraries accepted the 'none' algorithm — meaning no signature, just a header and payload. An attacker who modifies a JWT can change the algorithm in the header to 'none' and remove the signature, and a vulnerable library will accept it as valid. Always explicitly reject the 'none' algorithm in your JWT verification code. Modern JWT libraries (jsonwebtoken v8+, java-jwt) reject it by default, but always configure allowed algorithms explicitly.
How do I implement token revocation with JWTs?
JWTs are stateless — there's no central registry, so you can't 'invalidate' a JWT before it expires. Strategies: (1) Short expiry (15 min) + refresh token: revocation only needs to block the refresh token. (2) Blocklist: store invalidated JWT IDs (jti claim) in Redis with TTL matching the token expiry. Check the blocklist on every request. (3) Token rotation: issue a new access token and invalidate the old one on each use (detects token theft via use of revoked token). Strategy 2 is most common.