JWT Token Diff
Compare two JWTs claim by claim: see which claims changed, were added, or removed. Both tokens decode in your browser; nothing is sent to a server.
Paste both tokens above to see the diff
Compare two JWT tokens claim by claim
Paste two JWTs into the two boxes above and the tool decodes both entirely in your browser, then renders their header and payload claims side by side. Each claim is classified as same, changed, added, removed, or type-changed, with color-coded rows and a summary bar showing the counts at a glance. The diff is shallow: nested objects and arrays are compared as a whole, so a single field change inside an object marks the entire claim as changed.
Why did my token stop working?
The diff tool is built for the most common JWT debugging scenario:
a developer has a token that worked, receives a fresh one from the
auth server, and the new one fails where the old one worked. Instead
of eyeballing two decoded blobs, paste both here. The summary bar tells
you exactly how many claims changed, and the side-by-side view shows
which ones. Common causes the diff surfaces immediately: the
exp claim drifted past the current time after clock skew
between your server and the issuer, the aud (audience)
claim changed after an IdP configuration update so your API rejects it,
or the roles / scope claim changed between
environments. A dedicated algorithm banner appears when the signing
algorithm itself changed (for example HS256 to RS256), which is a
security-relevant change worth confirming.
Timestamp claims: exp, iat, nbf
The standard JWT timestamp claims are auto-detected and rendered with
both the raw NumericDate (the integer developers need to see) and a
human-readable UTC date. When both tokens carry the same timestamp
claim with different values, the changed side shows a signed delta
label such as +13 days or -2 hours. An
exp in the past shows an Expired badge
and an nbf in the future shows a
Not yet active badge, so clock-skew issues are
visible at a glance.
Share a diff with a teammate
Click Share diff link to copy a URL that encodes both
tokens into the fragment (the part after #). Browsers do
not send the fragment to servers in HTTP requests, so the encoded
tokens do not appear in server access logs or intermediate proxies.
A warning banner reminds you that anyone with the link can decode both
tokens: only share it over a trusted channel, and prefer tokens from a
non-production environment when possible. The link is generated only
when you click Share; the URL is not updated on every keystroke.
No data leaves your browser
Both tokens are decoded entirely in your browser using the Web Crypto API. There are no server requests during the diff. The only network call the site makes is the optional JWKS public-key fetch on the verifier, which you must initiate explicitly. You can confirm the zero-egress claim by opening DevTools Network panel while using the tool. As with any token inspection, avoid pasting tokens whose decoded payload contains data you would not want visible on your screen.
Frequently asked questions
-
How do I compare two JWT tokens?
Paste both tokens into the two input boxes on this page. The tool decodes each JWT in your browser and renders the header and payload claims side by side, highlighting which claims are the same, which changed, which were added, and which were removed. No token data is sent to a server: everything runs locally, so this is safe to use with production tokens.
-
Why did my JWT stop working after a refresh?
Compare the old (working) token and the new (failing) token here. The most common causes the diff surfaces immediately are: the exp claim drifted past the current time (clock skew between your server and the issuer), the aud (audience) claim changed after an IdP configuration update so your API rejects it, or the roles/scopes claim changed between environments. The summary bar tells you exactly how many claims changed, and the side-by-side view shows which ones.
-
Does the JWT diff tool verify signatures?
No. This tool decodes both tokens and compares their claims; it does not verify either signature. Decoding only reads the base64url-encoded JSON, which is reversible without any key. If you need to confirm a token was not tampered with, verify its signature on the main decoder page, which supports HS256/RS256/ES256 and JWKS endpoints.
-
Is it safe to paste production JWTs into this diff tool?
Yes. Both tokens are decoded entirely in your browser using the Web Crypto API; there are no server requests during the diff. The only network call the site makes is the optional JWKS public-key fetch on the verifier, which you must initiate explicitly. You can confirm the zero-egress claim by opening DevTools Network while using the tool. As with any token inspection, avoid pasting tokens whose decoded payload contains data you would not want visible on your screen.
-
Can I share a JWT diff with a teammate?
Yes. Click 'Share diff link' and a URL containing both tokens is copied to your clipboard. The tokens are encoded in the URL fragment (the part after #), which browsers do not send to servers, so they do not appear in server access logs. A warning banner reminds you that anyone with the link can decode both tokens: only share it over a trusted channel, and prefer tokens from a non-production environment when possible.
-
How are nested objects and arrays compared?
The diff is shallow: a claim whose value is an object or array is compared as a whole, not field by field. If two tokens both carry a user object but differ in one nested field, the entire user claim is marked as changed. Deep, recursive diff is planned but not yet built. Primitive claims (strings, numbers, booleans) and arrays are compared by value, and a type change (for example role changing from a string to an array) is flagged distinctly in orange.