Local-first
Every tool here claims your text is never uploaded. That is easy to write and impossible to tell apart from a lie by looking at the page. So here is how to verify it yourself, in about a minute, using tools already in your browser.
Vague claims cannot be checked, so this one is narrow on purpose.
What you type into a Jamuny tool is never sent anywhere. No request carries it, because the work happens in the page you already downloaded. There is no backend to receive it, no account, and no log of your content: not because of a policy, but because nothing transmits it.
Not that your visit is invisible. Cloudflare serves these pages, so like any host it sees your IP address and which URL you asked for. Anyone claiming otherwise about a website they run is misleading you. The distinction that matters is between that you visited and what you typed.
In rough order of how convincing they are. The last one needs no tools at all.
The list stays empty. Decoding, verifying and signing produce no requests at all, measured rather than asserted: zero outbound requests during all three.
Nothing third-party loads either. Every request the page makes is to this domain: the HTML, one stylesheet, the fonts. No CDN, no analytics, no tag manager. Fonts are self-hosted precisely because a request to Google Fonts would be a request carrying your IP to somebody else.
Try the same thing on board.jamuny.com: draw a few strokes, add a rectangle, open a second board tab, close it. The list stays just as empty. It is arguably the clearer demonstration of the two, since most whiteboard apps exist to sync a board to a server, and this one carries the same policy as the JWT tool: structurally unable to.
And on icons.jamuny.com: draw a shape, drag its points, change the canvas size, download the SVG. Measured with a headless browser driving the live site, the page makes five requests while loading — the HTML, its script and three fonts, all to that same domain — and then none at all, no matter what you draw. The download is built in the page and handed to your browser; it is never uploaded and fetched back.
And on pdf.jamuny.com: drop in a document and convert it. This is the one worth watching closely, because every other result for "convert to PDF" works by uploading your file. Driving the live site, every request it made was to that same domain — the page, two fonts, its script, and the conversion engine fetched at the moment converting began. The file itself never appears in the list, because it never leaves the tab: it is read, laid out and written to a PDF by code running in your browser, and the download is handed to you from memory.
The JWT tool, the whiteboard, the icon studio and LocalPress all setconnect-src 'none'. That is a browser-enforced rule saying the page may not open any network connection: no fetch, no XHR, no WebSocket, no beacon. It is not a promise about what the code does; it is a constraint the browser applies regardless of what the code tries.
curl -sI https://jwt.jamuny.com/ | grep -i content-security-policy
curl -sI https://board.jamuny.com/ | grep -i content-security-policy
curl -sI https://icons.jamuny.com/ | grep -i content-security-policy
curl -sI https://pdf.jamuny.com/ | grep -i content-security-policyRead the connect-src value in any of the four. With it set tonone, a build that tried to send your token, upload a board, post an icon or ship your document off to a converter somewhere would simply fail to send it.
One file on pdf.jamuny.com has a different policy: /edit-sw.js, the service worker that keeps the PDF editorworking offline. A worker is governed by the policy on its own response, and with connect-src 'none' it could not fetch the editor's files to keep them. Its policy is connect-src 'self': it can fetch from pdf.jamuny.com and nowhere else, and it only ever does so by GET, for the editor's own files.
It sits at the root of the site, so it controls every page on pdf.jamuny.com, the converter included. The editor starts two background workers of its own from /_astro/, and a browser matches those to a service worker by their own address, so a worker limited to /edit/ never saw them and no PDF opened offline. It answers only for the editor's own files. Nine of those the converter loads too: two fonts, the Arabic, Hebrew, maths and Chinese font packs, and three small shared scripts. On a converter page those nine come from the worker's cache on your device. Every other request goes to the network as it would with no worker at all. The page itself still cannot open any connection. The worker is one readable file: open it in the browser, or find it under DevTools, Application, Service workers.
curl -sI https://pdf.jamuny.com/edit-sw.js | grep -i content-security-policyLoad any tool, then turn off your Wi-Fi and keep using it. Decode a token, format some JSON, generate a hash, type into the notepad. Everything keeps working, because none of it needed the network in the first place.
This is the check that needs no technical knowledge and is the hardest to fake. Software that phones home stops working when it cannot.
Right-click and choose View Source on any tool page. What you get is the finished HTML: the text, the headings, the answers: not an empty shell waiting for a server. Turn JavaScript off entirely and the page still reads, because the content was never coming from anywhere else.
Local-first means the data is on your device, which is not the same as no data.
Documents are written to IndexedDB in your browser so they survive closing the tab. Per browser, per device: they will not appear on your phone.
Each keeps your most recent input in localStorage, so a stray reload does not lose a long list you had pasted in.
Boards are written to IndexedDB in your browser, the same mechanism as the notepad, with drawings kept separate from the boards themselves so a single pen stroke never re-saves every image on the page. Per browser, per device.
Clearing site data for the domain in your browser settings removes all of it, permanently and immediately. There is no copy anywhere else to delete.
You should not. That is the point. Every check below is something you run yourself against the live site. None of it depends on believing what is written here. If a check disagrees with a claim, the claim is wrong.
None that runs in your browser. There is no analytics script, no tag manager and no third-party request of any kind. Cloudflare serves these pages, so its own server-side logs record that a request happened, in the same way any web host knows it served you a page. Nothing measures what you do once the page has loaded.
That is not the claim, and it would be false. Cloudflare serves these pages, so like any host it sees your IP address and which URL you requested. What nobody sees is what you type into the tools, because that never becomes a request in the first place.
Nowhere, unless you save it. The notepad writes documents to IndexedDB in your own browser, and the converters keep your last input in localStorage so a stray reload does not lose it. Both are per-browser and per-device. Clearing site data deletes them permanently.
It could, which is why the checks matter more than the promise. On the JWT tool a browser test asserts zero outbound requests during decode, verify and sign; on the whiteboard, a separate test asserts the same while drawing, switching between board tabs and reloading. Both run on every deploy, but you can only take that on trust. The network panel you can see for yourself.