~/tools / 05 / jwt-token-claims
JWT Payload Simulator
Your route guards, RBAC middleware, and token-refresh logic all key off JWT claims — so mock the claims, not the crypto. Each template pairs a plausible signed-looking bearer token with its decoded header and payload, covering an administrator grant with write scopes and an already-expired token for testing your 401-and-refresh path. Signatures are decorative: never use these against a real verifier.
— validating —
$ man jwt-claims
Everything above is encoded into the #data= fragment of the exported URL — deflated and base64url-packed by your browser. Fragments are never sent to any server, so this mock is shareable and private. Paste the URL anywhere: a teammate's browser decodes it identically.
cat ./tldr.txt
A JWT claims mocker produces bearer token responses with custom claims — role, permission scopes, issuer, audience, and iat/exp timestamps — plus a decoded header and payload view, so RBAC guards and token-refresh paths can be tested without an auth server.
./when-to-use-this
- You need to confirm an admin-only route rejects an editor token without creating two real accounts in your identity provider.
- Your refresh flow has never been exercised because local tokens never expire.
- You are reviewing which claims the frontend actually depends on before changing the token contract.
./frequently-asked
- Are these tokens actually signed?
- No. The signature segment is decorative filler, so any verifier checking the HMAC or RSA signature will reject these tokens. They exist to exercise claim-shape logic — role checks, scope parsing, expiry handling — not cryptographic verification. Never point a real verifier at them and never use them as credentials.
- How do I test expired-token handling?
- Select the expired token template. Its exp claim is set roughly 24 hours in the past while the structure stays otherwise valid, which is what you want to drive the 401-then-refresh branch in your client without waiting for a real token to age out.
- What is the difference between scopes and roles in these claims?
- The templates carry both because they answer different questions. The role claim is a single coarse identity label such as admin or editor, typically used for route-level gating. The permissions array lists fine-grained capabilities such as billing:manage, typically checked at the action level. Most real bugs come from conflating the two.