Dev
Fake JWT Payload Generator
Building auth middleware, testing RBAC, or wiring a React component to a protected API all require tokens with the right structure — correct Base64URL encoding, standard claims, plausible expiry — without security risk. A fake JWT payload generator produces structurally valid JWTs (header.payload.signature) instantly, no auth server required. Each token includes a header (alg: HS256, typ: JWT) and payload with sub (UUID), name, email, role, iat (recent past epoch), exp (one hour after iat), and jti (unique UUID). The `role` input sets the role claim — user, admin, editor, viewer, or moderator — while all other claims stay structurally identical. The `count` input generates 1 to 20 tokens. Generate one admin and one user token to confirm your endpoint returns 200 vs 403 without setting up real accounts.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Set the count field to how many tokens you need — up to the available maximum.
- Choose a role from the dropdown: user, admin, or moderator, depending on the access level you want to simulate.
- Click Generate to produce tokens, each with a unique sub UUID, email, jti, and timestamps.
- Click the copy icon next to any token and paste it directly into an Authorization: Bearer header.
- Repeat with a different role to generate tokens for contrast testing without refreshing your work.
Use Cases
- •Testing Express middleware that should return 403 for user-role tokens on admin-only routes
- •Populating Postman or Insomnia collections with structurally valid Bearer tokens for each role
- •Seeding Storybook stories where components render different UI based on decoded role claims
- •Writing Jest or Vitest fixtures for JWT-parsing utilities without importing a real auth library
- •Mocking auth state in a React or Vue app during local development against a stubbed API
Tips
- →Generate one admin and one user token in the same batch so you can test forbidden-vs-allowed responses back to back without switching tabs.
- →If your test framework checks exp, note the token expires exactly 3600 seconds after generation — run time-sensitive tests immediately or mock Date.now().
- →Paste the payload segment into jwt.io to visually confirm all claims are present before wiring the token into a test suite.
- →In Vitest or Jest, store generated tokens as fixtures in a __fixtures__ folder so the same token is reused across test runs rather than regenerated.
- →When mocking a frontend auth context, decode the payload with atob() and pass the claims object directly to your AuthContext provider to simulate a logged-in state.
- →Use the jti (JWT ID) claim as a unique identifier in tests that verify token-revocation logic — each generated token has a distinct jti value.
FAQ
can I use these fake jwt tokens in production
No. The signature segment is a random placeholder, not a valid HMAC or RSA signature. Any production auth system that performs signature verification will return 401 Unauthorized immediately. Use these tokens only in development, testing, and documentation contexts where signature validation is disabled or bypassed.
how do I decode a jwt payload in javascript to inspect the claims
Split the token on dots to get three segments, then Base64URL-decode the middle segment (the payload). In Node.js: Buffer.from(segment, 'base64url').toString(). In the browser: atob(segment.replace(/-/g,'+').replace(/_/g,'/')). You can also paste the full token into jwt.io to decode it visually — it will display all claims and note that the signature is invalid.
what is the difference between the role options in the generator
Switching roles changes only the role claim inside the payload — sub, email, iat, exp, jti, and all other fields stay structurally identical. This lets you confirm that an endpoint returns 403 for a user-role token and 200 for an admin-role token without setting up multiple real accounts or database seed records.
what claims are included in every generated token
Every token payload includes: sub (UUID), name (first + last name), email (name@domain), role (your selected role), iat (issued at, recent past epoch), exp (iat plus 1–24 hours), and jti (UUID, unique per token). The header always contains alg: HS256 and typ: JWT. The signature segment is a random 43-character Base64URL string with no valid cryptographic value.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.