JWT Claims Editor
Edit and repackage JSON Web Token claims with ease.
JWT Claims Editor
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The JWT Claims Editor takes an existing JSON Web Token, decodes its claims into an editable form, and lets you modify them — adding, removing, or changing values — then re-encodes the result into a new token. This is specifically a testing and security-review tool: the most common reason to edit an existing token's claims is to verify that a backend actually validates the signature and rejects a token whose payload has been altered, rather than trusting whatever claims a client presents.
- This distinction matters because it's a genuinely common implementation mistake: some early or poorly-implemented JWT verification code checks that a token is well-formed and maybe checks the expiration, but fails to actually verify the signature against the expected key — which means any client could edit their own claims (elevate their role, extend their expiration) and the backend would accept it. Testing this specific failure mode is exactly what this tool is for: edit a real token's claims, and confirm your backend correctly rejects the result unless it's re-signed with a key the backend actually trusts.
- Because editing claims without access to the original signing secret necessarily invalidates the original signature, this tool re-signs the modified token with a key you provide — which won't match the original issuer's real secret unless you happen to know it. That's the point: it lets you produce a structurally valid but illegitimately-signed token to confirm your system correctly rejects it.
How It Works
- You provide an existing JWT (or start from a fresh set of claims, similar to the JWT Generator).
- The tool decodes the header and payload, presenting the claims in an editable form.
- You modify whichever claims you want to test — a role, an expiration, a subject identifier, or any custom claim.
- You provide a signing key to re-encode the token — this can be an arbitrary test key if you're specifically testing that signature validation catches the tampering, or the actual shared secret if you're doing legitimate claim manipulation in a system you control.
- The modified payload is re-serialized, re-encoded, and re-signed, producing a new, structurally valid token reflecting your edited claims.
Usage
- Paste an existing JWT into the input field, or start from scratch with a blank claims set.
- Review and edit the decoded claims — change values, add new custom claims, or remove existing ones.
- Provide a signing key to re-encode the modified token (use a deliberately wrong key to test rejection, or the real shared key for legitimate manipulation in a system you control).
- Copy the resulting re-signed token and use it in your test request against the target system.
- Confirm the target system's actual behavior matches what you expected — rejection for an untrusted signature, or correct authorization changes for a legitimately re-signed token.
Examples
- Editing a token's role claim from user to admin, re-signing with an arbitrary test key, and confirming a properly-implemented backend rejects it due to signature mismatch.
- Editing a token's exp claim to a past timestamp to confirm expired-token handling triggers correctly.
- Adding a new custom claim to a token to test how an application behaves when it encounters a claim it doesn't recognize.
- Reproducing a QA-reported bug by recreating the exact claim combination from a bug report, without needing to walk through the full login flow to generate it.
Real-World Use Cases
- Security-testing whether a backend correctly rejects a JWT whose claims were modified and re-signed with a key the backend doesn't recognize.
- Testing role-based or permission-based authorization logic by editing a token's role or permission claims and confirming access is granted or denied as expected.
- Reproducing a specific claim combination reported in a bug (an edge-case expiration, an unusual custom claim value) without needing to generate it through the full real login flow each time.
- Demonstrating to a team, during a security review, exactly how easy it is to alter an unsigned or weakly-verified token's claims, as a concrete illustration of why signature verification matters.
Best Practices
- Use claim-editing specifically to test signature verification, not just to check whether an application 'looks at' certain claims — the security-relevant question is always whether the backend rejects an untrusted signature, not just whether the claims themselves look valid.
- When testing legitimate claim changes (in a system you control, with the real shared key), keep clear records of what was changed and why, since a re-signed token is indistinguishable from a genuinely-issued one to anything that doesn't compare it against the original.
- Never use this tool to attempt to bypass authorization on a system you don't own or have explicit permission to test — that crosses from security testing into unauthorized access.
- Pair claim-editing tests with the JWT Inspector to confirm exactly what the resulting token decodes to before sending it, avoiding a wasted test cycle from an unintended claim value.
Common Mistakes
- Assuming that because a backend accepts a claims-edited token during testing, it must be validating claims correctly — always confirm specifically that it's checking the signature, not just parsing the payload without verification.
- Editing claims and forgetting to also update dependent claims — for example changing sub without updating any other claim that's supposed to be derived from or consistent with it.
- Testing only the 'happy path' edited claim (a role that should be granted) without also testing the negative case (confirming an untrusted signature is actually rejected).
- Confusing this tool's purpose with the JWT Generator's — if you're building a token from scratch rather than modifying an existing one, the Generator is the more direct tool for that.
Limitations
- Re-signing a modified token requires a key — this tool cannot forge a signature that will validate against a secret it doesn't have, which is exactly the security property it's meant to help you verify, not circumvent.
- It edits and re-signs the token structure correctly; it has no visibility into how your specific backend actually processes the result — you still need to send the token to your real system and observe its actual behavior.
- Claims and keys entered exist only in local browser memory for the session and are not persisted or transmitted anywhere.
Technical Reference Guide
- JSON Web Tokens and their claim structure are defined by RFC 7519; the signing mechanism this tool exercises when re-encoding a modified token is defined by RFC 7515 (JWS).
- A JWT's security guarantee rests entirely on signature verification against a trusted key — a backend that decodes and reads claims without verifying the signature against the expected key provides no actual integrity guarantee, regardless of how the claims look.
- The OWASP JSON Web Token Cheat Sheet documents the specific verification mistakes (including missing signature checks and algorithm-confusion attacks) this kind of claim-editing test is designed to catch.
FAQ
Can I use this to bypass authorization on a system I don't control?
You shouldn't, and in a correctly-implemented system you can't — editing a token's claims invalidates its original signature, and re-signing with a key the target system doesn't trust will be rejected. This tool is meant for testing systems you own or have explicit permission to test.
What's the difference between this and the JWT Generator?
The Claims Editor starts from an existing token's claims and modifies them, which is useful for reproducing a specific real-world token structure or testing tampering scenarios. The Generator builds a token entirely from scratch.
If I edit a token's claims, does the original signature still work?
No — the signature is computed over the exact encoded header and payload; changing the payload at all invalidates the original signature. The token must be re-signed, and unless you have the original signing key, it will be re-signed with a different, untrusted key.
Why would a backend accept a claims-edited token if the signature doesn't match?
It shouldn't, in a correctly-implemented system — if it does, that's exactly the kind of missing-verification bug this tool is meant to help surface during testing.
Is claim-editing itself insecure to use?
The tool operates entirely locally in your browser; the security question is about the target system you're testing against, not this tool. Never enter a real production signing secret into it.
Can I add claims that weren't in the original token?
Yes — you can add, remove, or modify any claim before re-encoding, which is useful for testing how an application handles unexpected or additional claims it wasn't designed around.
Part of this Developer Hub
This utility is part of our comprehensive Authentication & Tokens Lab topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the API & Web Engineering Lab workshop for complementary engineering workflows.
View all API & Web Engineering Lab tools