What a browser-only tool does and does not protect

It depends on whether the page sends it anywhere, and you can check that rather than trust it. A tool that runs entirely in the browser has no server to receive your input — the JavaScript that parses it is already on your machine, and no request carries the content. That removes the largest risk. It does not remove every risk: the page could change tomorrow, a browser extension can read the DOM, and a token that has been handled loosely should be rotated regardless.

What "no backend" means concretely

A static site is a set of files served as-is. There is no application process on the other end that could log a request body, because there is no request body — the parsing happens in JavaScript already running in your tab.

The way to confirm it is the network panel. Open developer tools, paste something, and watch: if the content is being sent, a request appears carrying it. On a genuinely client-side tool there is no such request, only the initial page and asset loads, and analytics or ad calls that carry page URLs rather than page content.

This is checkable in a way that a privacy policy is not. A promise is a claim about intent; the network panel is a record of what happened.

What it still does not cover

The page can change. The version you inspected is not necessarily the version you load next month, and static hosting makes updates trivially easy. For anything sensitive, the safer habit is to treat the check as valid for that session rather than forever.

Anything running inside your browser can read what you paste — extensions with page access, a shared or managed profile, and any script the page itself loads from a third party. A client-side tool moves the trust boundary to your own machine; it does not remove it.

The clipboard and browser history are ordinary places a value can persist. On a shared machine that matters more than the tool does.

Practical rules

Prefer an expired or synthetic value. A JWT you want to understand structurally decodes the same whether or not it is still valid, so use one that has already expired when you can.

Rotate what you paste anywhere you are not certain about. This is cheap for tokens and API keys and expensive only in the case where it turns out to have mattered.

For a secret that cannot be rotated — a signing key, a customer record under a retention obligation — do not use a web tool at all, however it is built. Use something local where the question does not arise.

Be more careful with tools that offer to verify a signature or decrypt something, because those need the key, not just the value. This site's JWT tool deliberately does not verify signatures for that reason: the feature would require you to paste the one thing you should never paste.

Tools for this

Specifications this follows

MDN — Same-origin policy — The browser boundary that separates a page from the rest of your machine.
MDN — Network request monitoring — How to verify for yourself whether content is leaving the page.
OWASP — JSON Web Token Cheat Sheet — Why a decoded payload is not evidence, and why signing keys stay on your machine.

Updated 2026-09-05