JWT Generator

Testing an API that accepts JWTs typically requires either an end-to-end auth flow or hand-encoding a token's three Base64URL-encoded sections. The first is overkill for local development; the second is tedious enough that most people copy stale tokens around until things break.

Fill in the header (defaults to HS256, none, or whichever algorithm you select) and the payload as JSON, and the tool produces a syntactically valid unsigned token you can paste into Authorization headers during testing. Standard claims like iat, exp, sub, and aud have shortcuts; custom claims accept arbitrary JSON values.

Unsigned by design — meant for development, mocking, and inspecting how a service handles different payloads. Don't use these tokens against production. Real signing requires a real secret, which is a different operation and out of scope here.

What a JWT actually is: three Base64URL-encoded JSON blobs joined by dots — header.payload.signature. The header declares the signing algorithm and token type. The payload contains claims (registered names like iss/sub/aud/exp/iat, plus whatever custom claims your application uses). The signature is the cryptographic seal: HMAC of the encoded header.payload using a shared secret (HS256/384/512), or an asymmetric signature using a private key (RS256, ES256, etc.). Validators recompute the signature from the header.payload using the corresponding key and compare; if it matches, the token's contents are trusted.

Worked example: header {"alg":"HS256","typ":"JWT"}, payload {"sub":"user-123","exp":1735689600,"role":"admin"}. Base64URL-encoded: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsImV4cCI6MTczNTY4OTYwMCwicm9sZSI6ImFkbWluIn0. Add an empty signature segment for an unsigned token, or sign with a real secret. The Authorization header carries it as Authorization: Bearer <token>. Decoding (e.g., at jwt.io) reveals the JSON immediately — JWT is signed but not encrypted, so anyone holding the token can read the contents.

The most dangerous edge case is alg confusion. A naive validator that trusts the header's alg field can be tricked: an attacker takes a token signed with RS256, switches the alg to HS256, and signs the new token using the public key as the HMAC secret. If the validator doesn't strictly enforce that incoming tokens use the expected algorithm, the attack succeeds. Modern libraries reject this by default, but the failure mode existed in real production systems for years. The "alg none" attack is a related variant — accepting unsigned tokens as if they were signed.

For production, prefer asymmetric signing (RS256, ES256) when validators don't need access to the signing key. The auth service holds the private key and signs; resource servers hold only the public key and verify. Compromising a resource server doesn't compromise token issuance. For monolithic applications where one service issues and verifies, HS256 with a strong secret is fine and faster. Don't use unsigned tokens in production for any reason — they're exclusively a development affordance.