Developer tools · JWT decoder
Why a JWT Decoder Needs No Server: Verifying With the Network Panel
· How it works
jwt privacy browser-processing
Splitting a string and decoding base64url is trivial work for a browser, so there is no technical reason for a decoder to send your token anywhere. This post shows how to confirm that a tool keeps it local.
Where does my token go when I press decode? — the question to ask of every online tool
Before using any online decoder, ask what receives the string after the button is pressed. A JWT may be a live bearer credential, so an upload can expose far more than readable claims. A page should not receive production tokens merely because its interface looks like a text formatter.
ToolAcre’s own warning is stricter than a marketing promise: do not paste production tokens into any web tool, including this one. Use an expired, rotated or synthetic example. The implementation runs locally, but browser extensions, surrounding scripts and the device remain part of the environment you must trust.
The work involved — string splitting, base64url decoding and JSON parsing, all standard browser capabilities
The actual decode consists of string operations and browser primitives. The code trims an optional Bearer prefix, splits on dots, normalises the base64url alphabet, restores padding, invokes `atob`, converts bytes through a strict UTF-8 TextDecoder and parses the first two results as JSON objects.
None of those steps requires a remote service. NumericDate rows use the local Date implementation, claim rows are assembled from the parsed object, and output is assigned as text. The source imports no verification library and asks for no secret or public key because inspection is the only operation offered.
How to check — open the network panel, paste a token, decode and watch for requests
Open developer tools before entering harmless test data, clear the Network list, perform the decode, then inspect new requests. Search request URLs, methods and bodies for the token or a distinctive substring. A request occurring at the same time is not automatically an upload; prove whether the credential bytes are present.
Keep the test controlled. Load the page first so asset requests have settled, use a unique synthetic marker in the payload, and avoid real credentials. If the marker appears in a request body, URL or header, the value left the local decode path. If it does not, the observation supports that session only.
A strict Content Security Policy narrows destinations; this page still loads disclosed scripts
The generated page includes a Content Security Policy whose `connect-src` permits self, blob and data destinations rather than arbitrary remote APIs. That meaningfully restricts ordinary script-initiated connections, but it does not justify the outline’s claim of “no third-party scripts, tags or analytics.” The broader product may load disclosed Google scripts.
CSP is defence in depth, not proof that every executable component deserves a credential. It can limit destinations while first-party endpoints remain allowed, and extensions operate under different privileges. Read the policy alongside the Network evidence and source; do not collapse those separate observations into “nothing can ever read this field.”
The decoder stores no token, but a reload test cannot prove every surrounding component is harmless
The JWT panel keeps its token in the editor value and does not call localStorage or sessionStorage. Clearing the panel removes its current values, and a reload does not contain a feature that restores the token. That narrower source fact supports a no-persistence statement about the panel itself.
A blank editor after reload is useful evidence, but not a universal storage audit. Browser history, clipboard managers, extensions, screenshots and operating-system facilities sit outside this module. Network and storage checks should therefore be described as reproducible observations, not as a guarantee about every layer on the device.
Worked example: distinguish ordinary page traffic from a request carrying token data
For a worked check, load ToolAcre’s JWT decoder, wait for initial page activity to finish and clear the request list. Paste the built-in expired sample or another non-sensitive token, press Decode and filter for a unique payload word. The header, payload, algorithm note and time rows should appear without a request carrying that marker.
Do not call the panel “empty” if analytics, site-connection or asset requests are visible. Record exactly what happened: ordinary page traffic may exist, while no inspected request included the synthetic token. That distinction is stronger evidence than hiding unrelated rows to make a privacy claim look absolute.
What this does not cover — browser extensions and clipboard managers, which sit outside the page's control
This procedure cannot inspect a malicious browser extension, clipboard history or a compromised operating system. It also cannot prove what code will do after a future deployment. Repeat it against the version and environment you intend to use, and prefer a local script you control when real credential material is unavoidable.
The Network panel also does not convert decoded claims into verified facts. Even when the token stays in the tab, ToolAcre does not authenticate it. Local processing reduces one disclosure route; it does not establish signature integrity, issuer identity, audience suitability or authorization.
Local ToolAcre code performs the decode, but a live token still does not belong in a website
ToolAcre performs its split, byte conversion and JSON parsing in browser code, and its tool-specific source contains no upload or persistence operation. You can test that behavior using synthetic data and developer tools instead of accepting a badge or privacy slogan at face value.
The correct takeaway remains conservative: verify the local path, but keep live access tokens out of websites. A decode-only client-side tool can be appropriate for throwaway diagnostics; it is not a credential vault, a verifier or an authorization service.