JWT Generator

What it does

JWT (JSON Web Token, RFC 7519) is the dominant token format for stateless web authentication and API authorization. A JWT consists of three Base64URL-encoded parts separated by dots: a header (declaring the signing algorithm and token type), a payload (the claims — sub for subject, exp for expiration, iat for issued-at, plus custom claims), and a signature (cryptographically signed digest of header + payload that lets the recipient verify the token wasn't tampered with). The output looks like “xxx.yyy.zzz” — a single string that can be passed in HTTP Authorization headers, cookies, or query strings.

The generator takes your header (typically{"alg": "HS256", "typ": "JWT"}), payload (your claims as a JSON object), and signing secret, and produces a properly-formatted JWT. Supported algorithms: HS256 (HMAC with SHA-256, the most common, uses shared secret), HS384, HS512 (longer hashes, same shared-secret model). For asymmetric signing (RS256, ES256), use a server-side library — shared-secret HMAC is appropriate when both signer and verifier are the same trust domain (e.g., your own backend issuing tokens for your own API).

Common JWT use cases: user authentication (server signs a JWT after login, client sends it on every subsequent request, server verifies signature without database lookup), API authorization (machine-to- machine tokens with specific scopes), single sign-on (one identity provider issues JWTs accepted by multiple services), and short-lived password reset / email verification tokens. Standard claims to include: sub (subject — user ID), iat (issued-at), exp (expiration — always set this; tokens valid forever are a security risk), aud (audience — which service should accept it), iss (issuer — which service signed it). Custom claims for your app: user roles, permissions, tenant ID. Don't put sensitive data in JWTs — they're base64-encoded, not encrypted; anyone with the token can read the payload.

How to use it

1. Fill in or accept the default header (alg + typ).
2. Write your payload as a JSON object — include sub, iat, exp at minimum.
3. Enter a signing secret (32+ random bytes recommended for HS256).
4. Pick algorithm (HS256 default for most cases).
5. Click Generate — copy the resulting JWT.
6. Test by pasting into jwt.io to verify it decodes correctly with your secret.

When to use this tool

• Testing JWT-based auth integrations during development.
• Generating sample tokens for API documentation or Postman collections.
• Quick token generation for ad-hoc API requests.
• Educational — understanding JWT structure by inspecting generated tokens.
• Mocking auth in test environments where you control both signer and verifier.

When not to use it

• Production token issuance — use a real auth library (jose, jsonwebtoken) or auth provider (Auth0, Clerk, Supabase Auth, AWS Cognito). Browser-based generation isn’t secure for production.
• Asymmetric signing (RS256, ES256) — that requires private keys which should never enter a browser tool. Use server-side libraries.
• Generating tokens with sensitive secrets — paste-in browser is fine for test secrets, dangerous for production secrets.
• Issuing tokens that need centralized revocation — JWTs are stateless; for revocation use opaque tokens or short-lived JWTs + refresh.

Common use cases

• Pre-decision sanity-check on inputs and outputs
• Educational use — demonstrating the underlying concept
• Onboarding a colleague who needs the same calculation/conversion
• Verifying a number or output before passing it on