[Feedback] Mention that JWT decoding happens fully locally

JWT.io
,
1

I noticed today that the design of the JWT decoder/encoder on jwt.io has changed.

There used to be a message saying that JWT decoding happens fully locally; the token is never sent across the wire.

In the new version, I don’t see that message anywhere on the page. This makes me doubt whether the approach has changed (though I suspect it hasn’t). For new users especially, it’s useful to keep this message to help them consider why it’s important that tokens are not sent to unverified third parties.

I like the visual refresh overall, but would love to see a way for this message to return as it was.

2

:plus: This factor of the redesign is especially jarring because there is a loading state between inputting a token and having it parsed. Digging through my network tab, it looks like that’s when calls to ./well-known/openid-configuration and ./well-known/jwks.json are pending?

It’s great that we’re able to pull more configuration information from the auth provider, but it is a bit unnerving to worry about whether my tokens are being sent out somewhere (and having to look through network logs to figure out what the purpose is)

3

Hi everyone!

I understand that you are asking whether the jwt.io debugger’s recent visual redesign changed its security model, and whether your JWT tokens are transmitted to Auth0 servers during the verification process.

The jwt.io debugger’s security architecture has not changed. All JWT decoding and signature verification occurs locally within your browser. Your tokens are never sent to Auth0 servers. The removal of the explicit security warning message and the addition of a loading state during the recent visual refresh are UI/UX changes only and do not reflect any change to the underlying secure architecture.

Root Cause: The loading state you observe occurs when the jwt.io interface automatically fetches the issuer’s public keys (JWKS) from the ./well-known/openid-configuration and ./well-known/jwks.json endpoints to verify the token’s signature. While these network requests are necessary for signature verification, the loading spinner appears without explanation, which can create the false impression that your token is being transmitted.

Solution: Understand what data is transmitted during jwt.io verification.

  1. Recognize that the loading state indicates the tool is fetching public keys from your token’s issuer, not transmitting your token itself.

  2. Confirm that your token is never included in these outgoing requests. Only the issuer’s public keys are retrieved.

  3. Trust that all token decoding and signature verification remains local to your browser. The public key fetch is a necessary step to verify the token’s authenticity, but it does not expose your token data.

Important note: The jwt.io debugger’s “local only” security model remains intact. The recent visual redesign improved the user interface but did not alter the security guarantees. If you are concerned about transmitting sensitive tokens to any online tool, you can always use a local JWT verification method or inspect the browser’s network tab to confirm that only public key requests are being made, never token data.

Please follow up if you have additional questions.

Kind Regards,
Nik

4

Thanks for your response. Great to know tokens are not transmitted. Would it be possibleto add an FAQ entry, or mention on the web page as before for those of us who need to be sure?

It would be great if there was no transmission at all, or if the debugger would ask first if it’s ok to fetch the token’s issuer JWKS. It might add a bit of friction but it would subjectively add to a sense of additional trust (think “oh wow, they really take this seriously” :+1: , which I don’t doubt btw)