JWT Generator
Build a signed-token preview from JSON header and payload data.
Overview
The JWT generator builds a signed JSON Web Token preview from a header and payload you supply. Edit the JSON objects, pick a signing algorithm and key, and the tool assembles the three dot-separated base64url segments ready to drop into an Authorization: Bearer header.
It is meant for backend developers prototyping auth flows, QA engineers crafting test fixtures, and anyone debugging a third-party JWT they need to round-trip with a known secret. A JWT generator online is also handy when you want to compare the output of your library against the canonical structure described in RFC 7519.
How it works
A JSON Web Token, defined in RFC 7519, is three base64url-encoded segments joined by dots: <header>.<payload>.<signature>. The header declares the signing algorithm (alg) and token type (typ). The payload is a JSON object of claims — registered ones like iss, sub, aud, exp, iat, nbf, jti, plus any custom ones you add. The signature is computed over base64url(header) + "." + base64url(payload). For HS256/384/512 it is an HMAC with a shared secret; for RS256/384/512 and ES256/384/512 it is an asymmetric signature with the corresponding private key. None of the base64url segments are encrypted — they are just signed, so never put secrets in the payload.
Examples
Header: { "alg": "HS256", "typ": "JWT" }
Payload: { "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }
Secret: your-256-bit-secret
Output: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header: { "alg": "RS256", "typ": "JWT" }
Payload: { "sub": "user-42", "exp": 1893456000 }
Output: <header>.<payload>.<RS256 signature>
Header: { "alg": "none" } (unsigned — accepted only by buggy verifiers)
Payload: { "admin": true }
Output: eyJhbGciOiJub25lIn0.eyJhZG1pbiI6dHJ1ZX0.
FAQ
HS256 or RS256?
HS256 is fastest and simplest but requires every verifier to hold the same secret. RS256 lets you sign with a private key and verify with a public key — essential when issuers and verifiers are different parties (e.g. OAuth providers).
Where do exp, iat, and nbf come from?
They are registered claims in RFC 7519. iat is "issued at", exp is "expires at", nbf is "not before". All are seconds since the Unix epoch (numeric, not strings).
Can I encrypt the payload?
Not with a plain JWT — use JWE (RFC 7516) for encryption. JWS, which is what this tool produces, only signs the payload; the contents are readable by anyone with the token.
Why is alg: none dangerous?
A long-standing class of bugs lets attackers craft tokens with alg: none and trick libraries into accepting them as valid. Always pin the expected algorithm in your verifier and reject anything else.