toolhq vs jwt.io: decode JWTs privately

If you work with authentication, you have almost certainly used jwt.io. It is the reference site for JSON Web Tokens: a clean decoder, well written documentation, a list of libraries by language, and an explanation of the standard that many engineers learned from. It earned its reputation, and any honest comparison should start by saying so.

toolhq also has a JWT decoder, and it sits inside a broader privacy first toolbox. This post explains where the two overlap, where they differ, and the one habit that matters more than which site you pick.

What a JWT decoder actually does

A JWT has three parts separated by dots: a header, a payload, and a signature. The header and payload are Base64URL encoded JSON, which means anyone can read them. They are not encrypted. Decoding a token simply reverses that encoding so you can see the claims inside: who issued it, who it is for, when it expires, and any custom fields your service added.

The signature is different. It proves the token was not tampered with, and verifying it requires the secret or public key. Decoding and verifying are separate jobs, and most day to day debugging only needs decoding: you want to read the exp claim, check the sub, or confirm a role is present.

How they compare

Both tools decode entirely in your browser. That is worth underlining, because it is the single most important property of any JWT tool.

| | toolhq JWT Decoder | jwt.io | | --- | --- | --- | | Decodes in the browser | Yes | Yes | | Free, no signup | Yes | Yes | | Signature verification | No, decode only | Yes | | Algorithm and library reference | Brief | Extensive | | Part of a wider toolbox | Yes | Focused on JWTs |

What each does well

jwt.io is the better choice when you need depth. It verifies signatures, supports a wide range of algorithms, and its documentation is a genuine teaching resource. If you are learning how JWTs work or debugging a signing problem, it is hard to beat.

toolhq is built for speed and focus. You paste a token, you read the header and payload, you check the expiry, and you move on. It lives next to the other tools you reach for in the same session, so you can decode a token, then hop to the Base64 tool or the JSON Formatter without changing tabs or context. There is nothing to learn and nothing to dismiss.

The rule that matters most

Here is the takeaway worth keeping: never paste a production token into a tool unless you are confident it stays in your browser.

A JWT often carries a live session. If it reaches a server you do not control, that session could in principle be replayed until it expires. This is not an accusation against any particular site. It is simply the correct default for anything that grants access. Treat tokens the way you treat passwords.

The honest, verifiable point about both jwt.io and toolhq is that they decode client side. jwt.io is open about this, and toolhq states it plainly: decoding happens in your browser and tokens are never transmitted. When you reach for any other tool, check that claim before you paste. If a site cannot tell you where your token goes, assume it goes somewhere.

A short practical workflow

Copy the token from your logs, header, or cookie.
Decode it to read the claims and confirm the expiry.
If a value looks wrong, trace it back to the service that issued the token rather than the decoder.
When you genuinely need to verify the signature, use a tool that supports it and the matching key.

For quick, local decoding that keeps the token on your machine, use the JWT Decoder. For deep reference work and signature checks, jwt.io remains an excellent destination. Both can sit in your bookmarks. The decoder you trust for production tokens should always be the one that never sends them anywhere.