Privacy policy — Developer Tools

Last updated: 30 August 2026

What the local tools do with pasted text

Developers hand secrets to online tools all day without meaning to. The token from a failing request goes into a decoder. The API response attached to a bug report — with a real customer's name, address and order in it — goes into a formatter. A Helm values file with internal host names and a service account goes into a YAML converter. In each case the ordinary tool sends that text to a server it does not describe, in a country it does not name, and the transfer is finished before anyone thinks to ask about it.

Most developer tools on this site do not send pasted text to a server. The pages may load local stylesheets, parser files or navigation helpers, and those requests can appear in the Network panel. There is no endpoint on this domain that accepts your pasted data. Nothing you type into those local tools is read by us, so it is not stored, logged, cached, sold or handed over — the material never exists on our side to begin with. Responsive Preview is different: scripts and remote resources inside pasted HTML can read the preview and send it elsewhere. Remove scripts and remote links before pasting confidential markup there.

Most local tools keep working with the network switched off. Load a page, disable your Wi-Fi or pull the cable, and carry on decoding: the answer still appears, because every calculation is running in JavaScript inside your own tab. Responsive Preview is the exception when it loads remote resources or a URL.

You can confirm it in about ten seconds without taking anyone's word for it. Open your browser's developer tools, go to the Network panel, clear the list, then paste your text into a local tool and use it. The list may show local stylesheets, parser files or navigation-helper requests; it should not show a request carrying the text you pasted to a server.

JSON Web Tokens specifically

A JWT is a bearer credential: whoever holds it can act as the subject it names until it expires, which makes pasting one into a web page a genuine risk worth thinking about. On the JWT decoder the token is split on its full stops, the header and payload segments are Base64url-decoded and parsed, and the claims are rendered — all of it in the tab, all of it in memory. The token is not sent anywhere, does not appear in any server log, is not written to a cookie, local storage or session storage, and is not retained after you close the tab or navigate away. It is never placed in the address bar either, so it cannot leak through your browser history or a Referer header.

The decoder also does not verify the signature, and that too is a privacy decision: verifying would require you to paste the signing key, and a secret typed into any web form is a secret you have to rotate. Read the claims here; check the signature where the key already lives.

What the hosting provider records

Serving you this page is itself a request, and our host writes the usual line in its access log: the IP address that asked, the path requested, the timestamp, the response code, the user-agent string and the referring page if your browser sent one. That is the standard record every web server keeps, it is used for security and for a rough idea of how many people visit, and the host discards it after a short retention period. We do not connect those lines to a person, and they contain nothing about what you did on the page once it had loaded — the log records that /tools/jwt-decoder/ was fetched, never what you subsequently pasted into it.

Cookies, storage and analytics

This site currently sets no cookies of its own and runs no analytics — no Google Analytics, no Plausible, no pixel, no session recorder, no error reporting service. If ads go live, the consent banner will store your answer in one local-storage entry so that the banner does not reappear on every page. It will contain a choice and nothing else, stay on your device, and be removed when you clear your site data. No tool writes your input to storage, and none of them keep a history you could accidentally leave behind on a shared machine.

Advertising (planned)

Hosting costs money, and the plan is to cover it with advertising, most likely Google AdSense; the empty slots marked out on the tool pages are where those units would go. When that happens the ad network will load its own content from its own servers and may set cookies or similar identifiers in your browser to count impressions, cap frequency and — depending on where you are and what you consented to — personalise what you are shown. Third-party vendors, Google included, use cookies to serve ads based on your previous visits to this and other sites. You can turn off personalised advertising from Google at Google Ads Settings, and manage other vendors at aboutads.info/choices. Where the law requires it — under the GDPR and the ePrivacy rules in the EEA and the UK, for instance — a consent banner will ask you before any non-essential cookie is set. This section will be rewritten with the specifics on the day advertising actually goes live.

Children

These tools are aimed at people writing software, not at children. The site is not directed at anyone under 13 and we do not knowingly collect personal information from them.

Your rights

We hold no personal data apart from the short-lived server logs described above, so in almost every case there is nothing to export, correct or erase — there is no account, no profile and no record of your use. If you think we hold information about you, or you want to ask what is in the logs for a particular time, get in touch and you will have an answer within 30 days.

Changes to this policy

If anything material changes here — most likely the introduction of advertising — the date at the top of this page will change with it. Carrying on using the site after that means you accept the revised version.