A JWT decoder offline rule for teams that handle production tokens

If your engineers debug login problems, they decode JWTs, and a JWT decoder offline (one that works in the browser with no server round trip) is the safest place for them to do it. The simplest rule for a team: production tokens go into a local tool such as AyeTab, never into a site that might post them back to its server.

Why this is an operations question, not a tooling one

A JSON Web Token is a bearer credential. Whoever holds a valid one can call your API as the user it was issued to until it expires. The payload is also readable by anyone: the jwt.io introduction says plainly that signed tokens are protected against tampering but not hidden, and that secret data does not belong in them unless the token is encrypted.

So when a support ticket escalates and an engineer copies the Authorization header out of the browser to see what is wrong, two things are in their clipboard: access to a real account, and whatever personal data your auth server put in the claims. Where they paste it next is a small decision with an outsized blast radius.

Most teams never write this down. People reach for the first search result, and the habit spreads from one engineer to the next.

What "offline" should mean

The word gets used loosely, so pin it to three checks:

A desktop app that never calls home passes all three. So does a browser tool that runs locally. A site that sends the token to its backend does not, however good its intentions.

The recommended setup

AyeTab fits the rule without asking engineers to change how they work. It is free, needs no account, and its JWT Debugger decodes the header, payload and signature in the browser. AyeTab states that input is not uploaded to its servers and that the page keeps working offline after it loads.

Engineers see the decoded claims in separate cards with copy buttons, and a chip on the payload says whether the token is still valid or when it expired. For a 401 at the end of a long day, that answer is usually the whole investigation.

There are two ways to roll it out:

• Web app. Point people at app.ayetab.com. It runs in Chrome, Firefox, Edge or Safari, so nothing has to be approved or installed.
• Chrome extension. The free AyeTab extension puts the same tools on the new tab page and in a side panel. Once installed it works offline, and it keeps favorites and recents on the machine.

Writing the policy

Keep it short enough that people remember it:

1. Decode production tokens only in an approved local tool.
2. Prefer test tokens from a staging tenant when reproducing a bug.
3. Never paste a token into chat, a ticket or a shared document; paste the decoded, trimmed claims instead.
4. If a token was exposed, revoke the session rather than waiting for it to expire.

Link the approved tool in your onboarding notes and your incident runbook, which is where people look when they are under pressure.

Where a different tool is right

Decoding is not verification. AyeTab reads tokens; it does not take a secret or a public key, and it does not issue tokens. When someone needs to confirm a signature or mint a test token, the debugger on jwt.io (from Auth0) has an encoder and optional signature verification, and your auth library can do both in code. Pair that with test keys, not production ones.

For the daily job of reading a token to see why a request failed, a local decoder is the right default, and AyeTab is the one we would standardise on.