Decode JWTs and Inspect Certificates — Safely, Locally

Every developer has done it: authentication is misbehaving, there's a JWT in the request headers, and the fastest move is pasting it into the first decoder Google offers. Except that token *is* a credential — it carries user IDs, emails, roles, and often enough authority to impersonate the session it belongs to. Pasting it into someone's website is handing over a key to see what the key looks like.

The uncomfortable truth about most online decoders is that you can't know what they keep. The comfortable alternative: decoders that never transmit, because they run where you are.

JWTs in sixty seconds

A JSON Web Token is three Base64-encoded parts joined by dots: header.payload.signature. The header says how it's signed; the payload carries the claims — who the user is, what they may do, when the token dies; the signature lets the *server* verify nothing was altered.

Key mental model: JWTs are encoded, not encrypted — anyone holding one can read it (which is why pasting it around is leaky, and why secrets never belong inside a token). The signature prevents *forgery*, not *reading*.

Debugging a token, locally

- exp — expiry (as a Unix timestamp; Unix Timestamp converts it, or spot it's in the past — the #1 cause of mysterious 401s).

- iat/nbf — issued-at and not-before, where clock-skew bugs live.

- aud/iss — audience and issuer; mismatches with your API's expectations are cause #2.

- Roles/scopes — is the permission actually *in* the token, or just in your assumptions?

1. Open JWT Decoder — decoding happens in your browser; the token goes nowhere.
2. Paste the token; header and payload appear as formatted JSON.
3. Read the claims that answer 90% of auth bugs:

What a local decoder deliberately doesn't do: *verify signatures* — that requires the signing secret, which should live on servers, not in browser tools. Decode to inspect; let the backend verify.

Certificates: reading the machinery of HTTPS

The other credential you'll eventually need to read is an X.509 certificate — the document behind every HTTPS padlock. SSL Certificate Decoder parses a certificate (PEM paste or file) into human-readable facts:

• Validity window — expired certificates are the classic 2 a.m. outage; check Not After before it checks you.
• Subject and SANs — which domains the cert actually covers (the www vs apex mismatch lives here).
• Issuer chain — who vouches for it, and whether the intermediate you're deploying matches.
• Key algorithm and strength — spotting the ancient RSA-1024 or SHA-1 cert that an auditor will flag.

Same privacy logic applies: certificates you're *deploying* (with their context of infrastructure details) parse locally rather than in some web form's logs.

The wider local-inspection toolkit

Debugging credentials pairs with neighbors from the same drawer: Hash Generator for comparing fingerprints (cert pinning checks), Base64 Decode for the odd raw segment, and Password Strength Checker when the investigation turns to the credentials users chose. The whole Security & Privacy set follows one rule — secrets are inspected where they already are, never exported to be examined.

Frequently Asked Questions

Is it ever OK to paste a production JWT into an online decoder?

Into a server-side one, no — treat it like pasting a password. Into a local decoder, yes: nothing leaves the page, which you can verify by decoding while offline. Better still, use expired or staging tokens when possible.

My token decodes fine but the API rejects it — why?

Decoding ≠ validity. Check exp first, then aud/iss against the API's config, then whether the API expects a different signing key (rotated secrets invalidate old tokens without changing how they decode).

How do I check when my website's certificate expires?

Paste the certificate into SSL Certificate Decoder and read Not After — then set a calendar reminder well before it, because "the cert expired" outages are 100% preventable and 100% embarrassing.

Can I verify a JWT's signature in the browser?

Technically possible with the public key for asymmetric algorithms, but the meaningful verification belongs to the consuming server — browser tools are for *reading* tokens during debugging, not for making trust decisions.

Next auth mystery, keep the credentials home: open JWT Decoder, read the claims, find the stale exp — companion instruments at Security & Privacy.