Dummy JWT Generator
Generates realistic-looking but fake JSON Web Tokens for testing token handling
Generated 1 word · 146 characters
About this generator
Testing token-handling code — parsing, storage, header injection, and rejection — should not require a running auth server or a valid signing key. This generator produces dummy JWTs with the correct three-part dot-separated structure (header.payload.signature) in base64url-style encoding, so your code sees a token that looks exactly right without being cryptographically valid. The role claim dropdown sets which role is encoded into the payload: user, admin, guest, or service. Generating tokens with different roles lets you test access-control branches — does the admin role unlock a UI panel? does a guest token correctly hit a 403? — without minting real tokens with your signing key. The header encodes alg: HS256 and typ: JWT; the payload encodes sub (a random 16-character subject ID), role, iat (a random issued-at timestamp), and exp (a fixed future expiry). Important: the payload is not proper base64url encoding and the signature is a random string, not an HMAC. These tokens will fail signature verification. They are suitable for testing token parsing, Authorization header transport, and UI display logic — not for authenticating against any real endpoint.
How to use
- Choose the role claim you want the token to represent.
- Click Generate to produce a realistic-looking dummy JWT.
- Copy it into your test request, fixture, or documentation.
- Use it to verify token parsing and transport, not real authentication.
Use Cases
- •Testing how your client stores and sends bearer tokens
- •Verifying that token-parsing code splits header, payload, and signature
- •Fixtures for tests that expect an Authorization header
- •Confirming your server rejects unsigned or invalid tokens
- •Placeholder tokens in API documentation and examples
Tips
- →Use these to confirm your server correctly rejects tokens with invalid signatures.
- →Generate tokens with different roles to test access-control branches.
- →For real authentication tests, mint tokens with your actual signing key in a sandbox.
- →Never paste a dummy token where a genuinely valid one is required.
FAQ
are these real jwts that will authenticate
No. These tokens have the correct three-part shape but are not signed with any real key, so they will fail genuine signature verification. They are for testing token handling and storage only, never for authenticating against a real service.
what are the three parts of a jwt
A JWT has a header, a payload, and a signature, joined by dots and each base64url-encoded. The header names the algorithm, the payload carries claims like the subject and expiry, and the signature lets a server verify the token was not tampered with.
why test with a fake token instead of a real one
Real tokens contain valid signatures tied to a secret and often expire quickly, which makes them awkward and unsafe to hard-code into tests. A dummy token gives you a stable, shareable value to exercise parsing and transport logic without leaking anything.
what claims does the generated token payload include
The payload contains four claims: sub (a random 16-character subject ID representing the user), role (the value you selected from the dropdown), iat (a randomly chosen issued-at Unix timestamp), and exp (a fixed future expiry timestamp). The header contains alg: HS256 and typ: JWT.
You might also like
Popular tools from other categories that share themes with this one.