JWT Encoder & Generator — Create and Sign JSON Web Tokens Online
1. Algorithm, header, payload, and claims
alg is written here immediately. Custom fields such as kid are preserved.
.json file here or paste an object. JWT claims are readable unless separately encrypted.
2. Key, generation, and output
Key safety: never enter production secrets or private keys into any online page. Use controlled offline tooling for sensitive material.
Generated token inspection
- Algorithm
- Token length
- Signature
- Claim status
Press Ctrl/Cmd + Enter in either JSON editor to generate. Editor content is preserved when algorithms change.
Advertisement
How JWT signing works
header.payload.signature
1. Header JSON
{"alg":"HS256","typ":"JWT"}Base64URL: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
2. Payload JSON
{"sub":"user-123","exp":1893456000}The payload contains claims, not automatically confidential data.
3. Signature
HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)
The exact HS256 input is the two encoded segments joined by a dot.
Base64URL is encoding, not encryption. Anyone holding a signed JWT can decode its header and payload. A valid signature shows that signed bytes have not changed and were produced with the signing key; it does not make the claims secret.
Algorithm, claims, and troubleshooting guide
HS256 vs RS256 vs ES256
| Choice | Key model | Good fit | Main caution |
|---|---|---|---|
| HS256 | One shared secret | A single trusted boundary signs and verifies | Every verifier can also mint tokens |
| RS256 / PS256 | RSA private/public pair | Several services verify without the private key | Protect the private key; use at least 2048-bit RSA |
| ES256 | P-256 private/public pair | Compact signatures and modern asymmetric deployments | Key format and curve must match exactly |
Registered JWT claims
iss names the issuer, sub names the subject, aud identifies intended recipients, exp sets expiry, nbf delays validity, iat records issuance, and jti provides a token identifier. Time claims are Unix seconds in UTC. Applications must explicitly validate the claims they depend on.
Common generation errors
- Invalid JSON: property names and strings require double quotes; remove trailing commas.
- Signature mismatch: check algorithm pinning, secret encoding, PEM type, and whether whitespace changed the signed bytes.
- Token rejected: confirm issuer, audience, clock skew, expiry, required scopes, and the API's expected key.
- PEM import failed: use an unencrypted private key with the correct RSA or P-256 format.
JWT security guidance
- Prefer short expirations, validate
issandaud, and allow only a small intentional clock skew. - Pin the expected algorithm in the verifier; never trust the token's
algvalue as configuration. - Rotate keys, publish only public verification keys, and use a meaningful
kidto select the active key. - Use unpredictable HMAC secrets at least as strong as the hash output and protect asymmetric private keys.
- Never accept
alg=nonein production. This generator exposes it only for isolated compatibility testing.
Generating a token does not prove that an API will accept it. Signature verification checks cryptographic authenticity; claim validation separately enforces expiration, issuer, audience, subject, and application policy.
Primary references: RFC 7519 (JWT), RFC 7515 (JWS), RFC 8725 (JWT Best Current Practices), and OWASP JWT guidance.
Implementation and review
This page signs and verifies locally with the browser Web Crypto API. It follows the JWS/JWT algorithm identifiers in RFC 7515 and RFC 7518 and accepts raw HMAC bytes, unencrypted RSA PKCS#8/PKCS#1 PEM, and unencrypted P-256 PKCS#8 PEM.
Reviewed by: Starlight Tools engineering team · Last reviewed: 18 July 2026 · Each generated signature is immediately self-checked with the supplied or derived verification key. Representative HS256 output was also cross-checked against Node.js crypto.createHmac, and the remaining algorithm paths follow the published JOSE requirements.
JWT encoder and generator FAQ
Does anything I type get uploaded?
No. The encoder runs entirely in your browser. Nothing is sent to any server.
Are JWTs encrypted?
No. A standard signed JWT (JWS) is Base64URL-encoded, so its header and payload remain readable. Signing detects changes; it does not hide claims.
Which JWT algorithm should I choose?
Use an algorithm required by the system you are testing. HS256 is simple when one trusted service signs and verifies. RS256, PS256, or ES256 let verifiers use a public key without receiving the private key. Never allow an attacker to choose the accepted algorithm.
What is the difference between text and Base64 HMAC secrets?
Text mode signs with the UTF-8 bytes of the characters entered. Base64 mode first decodes the value to raw bytes. The modes produce different signatures unless those resulting bytes are identical.
Which PEM private-key formats are accepted?
RSA accepts unencrypted PKCS#8 PRIVATE KEY and PKCS#1 RSA PRIVATE KEY PEM. ES256 accepts an unencrypted PKCS#8 PRIVATE KEY for a P-256 key. Password-encrypted PEM files are not supported.
How do JWT expiration timestamps work?
The exp, iat, and nbf registered claims use NumericDate values: whole Unix seconds since 1970-01-01T00:00:00Z. Verifiers should compare exp and nbf with the current time while allowing only a small, intentional clock skew.
Is it safe to paste a production secret or private key here?
Do not paste production keys into any online page. This tool processes values locally, but a dedicated offline and controlled environment is the safer choice for sensitive key material.
What is the difference between encoding, signing, decoding, and verification?
Encoding converts JWT JSON to Base64URL text. Signing creates a cryptographic signature. Decoding makes the readable header and payload visible without proving authenticity. Verification checks the signature; claim validation separately checks rules such as issuer, audience, and expiration.