Privacy

No server ever receives your data

Encoding and decoding happen in JavaScript, in this tab. There is no upload, no account, and nothing on the other end of a request, because this page is not permitted to make one: it ships a Content-Security-Policy containing connect-src 'none', which blocks every kind of outgoing connection a page can make — fetch, XMLHttpRequest, WebSocket, navigator.sendBeacon, an <img> or stylesheet pointed at another host — after the page has loaded. It is not a setting we could quietly turn off without it showing: any future change to it is a named, dated exception, logged as such, never a quiet edit.

Check it yourself

Open your browser's developer tools (F12, or right-click → Inspect) before you do anything else on this page:

• Network tab. Convert some text on the tool page. Nothing new appears in the list after the page's own initial load — no request goes out no matter what you type, paste, or click.
• Console tab. Paste fetch("https://example.com/") and press Enter. The browser itself refuses it and reports why: Refused to connect because it violates the document's Content Security Policy. That is the browser enforcing the header, not this page choosing not to try.
• Network tab, Headers. Click the document request at the top of the list and read the response headers. The Content-Security-Policy line is there in full, sent by the server before a single line of this page's JavaScript runs.

No ads, no analytics, no cookies — and so no consent banner

There are no advertisements, no analytics or telemetry of any kind, and no cookies. A consent banner exists to ask permission for tracking that would otherwise happen; there is nothing here that would otherwise happen, so there is nothing to ask permission for.

Check it yourself

• Application tab → Cookies. Pick this site's origin. The list is empty, and stays empty however you use the tool — nothing here ever calls document.cookie or sets a Set-Cookie response header.
• Network tab. No request to any analytics, advertising, or tag-management domain appears, because connect-src 'none' above would block it even if the code tried — and the code does not try; there is no such code in this product to remove a flag from.

What is kept between visits — and what never is

Three preferences are written to this browser's localStorage, under this site's own origin, so they are remembered the next time you open the page: your theme (jwv-theme), your accent colour (jwv-accent), and whether live conversion is on (b64-live). That is the complete list. None of them can hold your text — each is one of a small, fixed set of words (system/light/dark, blue/violet/teal, on/off), so there is no code path by which anything you type or paste could end up in one.

Your input and output text are never written to localStorage, in any form, ever. They exist only as the live value of the two boxes on the tool page and in memory while the tab is open.

One narrower exception, stated precisely rather than glossed over: clicking "Open in Json Web Viewer" — offered only when decoded output is itself valid JSON — writes that decoded text to sessionStorage for the moment it takes to hand it to the flagship editor, under the key b64-jwv-handoff. sessionStorage is not localStorage: it belongs to this one browser tab, is never sent anywhere over the network by the browser itself, and is discarded automatically when the tab closes. It exists only if you press that specific button, holds exactly the text that was already on your screen, and is not how anything reaches the address bar — see the next section.

Check it yourself

• Application tab → Local Storage. Change the theme or accent, or toggle live conversion, and watch the corresponding entry appear or change. Type or paste anything into either pane and nothing new appears here — ever.
• Application tab → Session Storage. Decode some Base64 whose result is JSON (for example eyJhIjoxfQ==) and click "Open in Json Web Viewer" — b64-jwv-handoff appears here, holding exactly {"a":1}, for as long as this tab stays open.

Your text is never in the address bar either

A link to this tool can only carry your settings — direction, character set, and the formatting options — never your text. The code that writes the address bar (buildQuery()) is handed only that settings object; it is never given your input or output, so there is no path by which it could put either into a URL even if it tried. A dedicated test pins the exact, short list of names that function is allowed to write.