Why a separate set of tools?
Testing an API is rarely one clean action. You send a request, get back a 401 Unauthorized, and suddenly you need to know what is actually inside the token you sent. Or an endpoint returns 4 KB of minified JSON on a single line and you need to find one nested field. Or you are building a query string by hand and a customer's name contains an ampersand that quietly breaks the whole request.
Each of those detours has the same shape: a small transformation on a string. That is what these tools are for. They sit alongside the main API tester so you never have to leave the site, open a scratch file, or paste a production access token into an unknown website to find out what it says.
Everything runs client-side
This matters more than it sounds. Tokens, request bodies and query strings routinely contain credentials, customer email addresses, internal identifiers and session data. Many online "decoder" sites post that content to a server before showing you the result, which means a copy exists somewhere outside your control. These five tools are implemented in plain JavaScript inside the page. Open your browser's network tab while you use them and you will see no requests at all. You can load a page, disconnect from the network, and every tool still works.
How they fit together
They chain naturally. A JWT is three Base64url-encoded segments joined by dots, so the
Base64 decoder and the JWT decoder are
solving nearby problems — the JWT tool just knows the structure and the standard claim names. An
Authorization: Basic header is a Base64-encoded user:password pair, which is why
Base64 shows up whenever you are reading HTTP headers. Decoded JWT
payloads and API responses are both JSON, so the JSON formatter is
the next stop when a payload gets large. And a query string full of %20 and %3D
is a job for the URL decoder.
A note on trusting output
Decoding is not validating. The JWT decoder will happily show you the contents of a token whose signature is forged, because reading the payload and verifying the signature are genuinely different operations — the second one requires a secret key that only your server should hold. The same caution applies everywhere here: these tools tell you what a string says, not whether it is authentic or whether the server that issued it still considers it valid. Treat their output as information for debugging, and keep authorisation decisions on the server.