Dev

Fake JWT Payload Generator

A fake JWT payload generator gives developers realistic mock JSON Web Tokens without spinning up an auth server. When you're building authentication middleware, writing integration tests, or wiring up a React app to a protected API, you need tokens that look real — correct structure, plausible claims, proper Base64URL encoding — but carry no security risk. This tool produces exactly that. Each generated token follows the standard three-part header.payload.signature format and includes the claims most auth systems actually use: sub (user ID), name, email, role, iat (issued at), exp (expiration 1 hour out), and jti (a unique token ID). You can generate tokens for different roles — user, admin, moderator — to test role-based access control branches in your code. The role selector makes it easy to reproduce specific scenarios. Need to confirm your middleware blocks a 'user' from an admin-only endpoint? Generate a user-role token, paste it into your Authorization header, and fire the request. No mocking library required, no seed data to configure. These tokens are unsigned, which means any signature verification step in your app will reject them in a real auth flow — that's intentional. Use them in unit tests where you bypass signature checks, in Postman collections where you just need a structurally valid Bearer token, or in Storybook stories where components read claims from a decoded payload. They cover the vast majority of front-end and middleware testing scenarios without any backend dependency.

How to Use

  1. Set the count field to how many tokens you need — up to the available maximum.
  2. Choose a role from the dropdown: user, admin, or moderator, depending on the access level you want to simulate.
  3. Click Generate to produce tokens, each with a unique sub UUID, email, jti, and timestamps.
  4. Click the copy icon next to any token and paste it directly into an Authorization: Bearer header.
  5. Repeat with a different role to generate tokens for contrast testing without refreshing your work.

Use Cases

  • •Testing role-based middleware that blocks non-admin users
  • •Populating Postman or Insomnia collections with Bearer tokens
  • •Seeding Storybook stories that read user claims from a decoded token
  • •Writing Jest or Vitest unit tests for JWT-parsing utility functions
  • •Mocking auth state in a React or Vue app during local development
  • •Generating multiple tokens to stress-test a token-rotation endpoint
  • •Verifying frontend UI differences between user, admin, and moderator roles
  • •Providing realistic token fixtures for API documentation examples

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

What is a JWT payload?

The payload is the second of the three dot-separated sections in a JWT. It's a Base64URL-encoded JSON object containing claims — key-value pairs like sub (subject/user ID), email, role, iat (issued at timestamp), and exp (expiration timestamp). It's not encrypted, so anyone can decode it; it's only tamper-evident when the signature is verified.

Can I use these fake JWTs in production?

No. These tokens are unsigned — the signature segment is a placeholder, not a real HMAC or RSA signature. Any production auth system performing signature verification will reject them. Use them only in development, testing, or documentation contexts where signature validation is disabled or irrelevant.

How do I decode a JWT payload manually?

Split the token on the dots to get three parts, then take the middle segment and run it through a Base64URL decoder. In Node.js: Buffer.from(segment, 'base64url').toString(). In the browser: atob(segment.replace(/-/g,'+').replace(/_/g,'/')). jwt.io also decodes any token visually in seconds.

What claims does each generated token include?

Every token includes: sub (a UUID acting as user ID), name, email, role (whatever you selected), iat (current Unix timestamp), exp (iat plus 3600 seconds, i.e. one hour), and jti (a unique token identifier). These cover the claims used by most standard auth libraries like jsonwebtoken and passport-jwt.

How do I use a fake JWT in Postman?

Copy a generated token, open your Postman request, go to the Authorization tab, select 'Bearer Token' from the type dropdown, and paste the token in. Postman will attach it as an Authorization header automatically. If your server skips signature verification in a test environment, requests will pass through as authenticated.

What's the difference between the user, admin, and moderator roles?

The role value changes only the role claim inside the payload — the rest of the structure is identical. This lets you test role-based access control logic: for example, confirming that an endpoint returns 403 for a user-role token but 200 for an admin-role token, without needing multiple real accounts set up.

Why is the exp claim set one hour in the future?

One hour is the most common default expiry used by auth servers like Auth0, Keycloak, and AWS Cognito. It means tokens are immediately valid and won't appear expired in your test assertions unless you intentionally manipulate the value. If you need an already-expired token for testing, subtract time from the iat and exp values after decoding.

Can I customize the claims or add extra fields?

The generator currently produces a fixed claim set covering the most common use cases. To add custom claims, decode the payload section, edit the JSON, re-encode it with Base64URL, and reconstruct the token string. Since the signature won't match anyway, this works fine in test environments where signature checks are skipped.