Random Fake JWT Generator

Fake JWTs for SDK and UI testing

A JSON Web Token (RFC 7519, 2015) is three Base64url-encoded segments joined by dots — header.payload.signature. A "fake" or "mock" JWT keeps the shape but replaces the signature with random bytes (or a known dummy secret), so the token looks like the real thing without granting access to anything. That is exactly what you want when designing an SDK, mocking an OAuth flow in Postman, seeding a Storybook story, building a JWT decoder UI, or recording API SDK fixtures for tests.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decode each segment as Base64url and you get JSON. The header declares the algorithm: {"alg":"HS256","typ":"JWT"}. The payload holds claims: standard ones (iss issuer, sub subject, aud audience, exp expiration, nbf not-before, iat issued-at, jti JWT id), public ones registered in the IANA JWT claim registry, and private app-specific ones. The signature is what gates trust; without it a JWT is a glorified Base64 string.

Algorithms and where each fits

• HS256 / HS384 / HS512 — HMAC with a shared secret. Symmetric: issuer and verifier hold the same key. Default for single-service backends.
• RS256 / RS384 / RS512 — RSA signature. Asymmetric: sign with private, verify with public. Right when many services verify what one service issues.
• ES256 / ES384 / ES512 — ECDSA on NIST curves. Same asymmetric story as RS*, shorter signatures.
• EdDSA — Ed25519. Modern, fast, no parameter footguns. Increasingly recommended.
• none — the famous footgun: no signature at all. Libraries must refuse it; the original alg=none attack was a generation of identity bugs.

Token lifetimes

Mature APIs split credentials in two: a short-lived access token (5–15 min) carried on every request and a long-lived refresh token (days or weeks) stored in HttpOnly + Secure cookie. When the access token expires the client trades the refresh for a new pair; the refresh itself rotates and is revoked on reuse. This limits the blast radius of a leaked access token to a quarter of an hour. Tools that help: jwt.io (Auth0's interactive decoder), jwt-cli, jose in Node, PyJWT in Python, the JWKS endpoint convention (/.well-known/jwks.json) for key distribution.

Vulnerabilities to keep on the radar

Three classic JWT bugs keep returning. alg=none: an attacker forges a token with no signature; a misconfigured library accepts. Key confusion: a server expects RS256 and exposes a public key; the attacker switches the header to HS256 and signs the token using the public key as the HMAC secret. Signature stripping: dropping the third segment and hoping the verifier reads the payload anyway. Mitigations: always pin the algorithm list on verify ({ algorithms: ['RS256'] }), never trust header-supplied URLs (jku / x5u), and store tokens in HttpOnly cookies — never in localStorage, which is reachable from any XSS.

FAQ

Is this useful for testing? Yes — that is the entire point. Use it to seed Postman collections, Storybook fixtures, SDK design mocks and decoder UIs.

Can a fake JWT forge real access? No. Without the real signing secret or private key, every backend that validates correctly will reject it. The fake token is shaped like the real thing but signed with random bytes.

Where do I store JWTs safely on the web? HttpOnly + Secure + SameSite=Lax cookies for refresh tokens; access token in memory only. Avoid localStorage: any XSS reads it.

JWT vs JWE? A standard "JWT" is signed only — the payload is plaintext. JWE (RFC 7516) is the encrypted variant when the contents must stay secret from the holder.

Should I ever use this token in production? Never. It is a placeholder. Real tokens are issued by your auth server signing with a properly generated secret or key.