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.
1 Like
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)
1 Like
Hi everyone!
To put your mind at ease immediately: the approach has not changed. The jwt.io debugger still performs all JWT decoding and signature verification entirely locally within your browser. Your tokens are never sent across the wire to Auth0 servers. The removal of the explicit warning message was simply a UI/UX decision during the recent visual refresh, not a change in the underlying secure architecture.
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?
The loading state you are seeing is the new jwt.io interface automatically attempting to fetch the public keys (JWKS) from the token’s issuer to automatically verify the signature for you. I can confirm that your token is not included in these outgoing requests , but you are entirely correct that adding a loading spinner without explaining why network calls are happening can work against the tool’s “local only” security promise.
If you have any other questions, let me know!
Kind Regards,
Nik