Privacy, enforced — not just promised

Most converters that say "your data never leaves your browser" are asking you to trust their word. This page shows the mechanism, and lets you check it yourself.

0outbound requests since this page loaded, counting everything except the analytics script that logs the page view. Convert a statement above and watch it stay here.

Try it: convert a statement right here

Watch the counter above while you do it — or open your browser's Network tab and watch that instead.

The browser enforces it, not just our code

Every page on this site is served with a Content-Security-Policy header whose connect-src lists exactly one destination: Google Analytics, which records that a page was viewed. Every other origin is refused by the browser — no fetch(), no XMLHttpRequest, no WebSocket and no beacon can reach anywhere else, even if a bug or a future change tried to add one. Critically, this site has no server-side endpoint of its own, so there is nothing to receive a statement even in principle: the analytics script sees URLs, never file contents, and it is never given any. You don't have to trust our intentions — read the header and check it against the list below.

One third-party script, and it never sees your file

pdf.js and every other library that touches your statement are bundled and served from this domain, not loaded from a CDN at runtime. The single exception is Google Analytics, which counts page views so we know which guides are worth writing. It runs at page level only — it is not wired into the converter, it receives no filename, no bank name, no amount and no parsed row, and it cannot read the file because the file is never handed to it. Everything the converter does with your PDF happens in memory in your tab and stops there.

It works with your internet off

Once this page has loaded, disconnect from the internet and convert a statement — it still works. That's the practical test of "never leaves your browser": if it needed a server, it couldn't run offline.

Verify it yourself in under a minute

You don't need to take any of the above on faith — every browser ships the tools to check it. This works on this site, and it works on any converter you're considering using instead.

Open DevTools before you upload anything. Right-click the page → Inspect (or F12 / Cmd+Opt+I), then click the Network tab. Check "Preserve log" if it's offered — it stops the list from clearing between page loads.
Convert a statement. Drop a PDF in above, let it parse and reconcile, and export it in whatever format you'd normally use.
Read the Network tab. You'll see requests for this page's own HTML, CSS, and JavaScript files — that's normal, the app itself has to load, plus a request to googletagmanager.com and one to google-analytics.com as the page loads — that's the page-view counter, and it fires before you touch the converter. What you should not see, at any point during parsing or export, is a single new request of any kind: dropping a PDF in, reconciling it and exporting it should add nothing at all to that list. If a converter you're testing does add one, that's the statement's contents — or metadata about it — leaving the browser.
Check the response headers, if you want to go further. Click the top-level document request, open the Headers tab, and look for Content-Security-Policy. On this site its connect-src names only the analytics hosts above and no other destination — that's the browser-enforced rule discussed above, visible in the raw response the server actually sent.

Most competing converters will fail step 3 the moment you drop a file in, because their entire model depends on receiving your PDF on a server somewhere. That's not necessarily a sign of bad faith — some of them do things this tool can't, like OCR a scanned statement, which genuinely requires server-side processing. But "secure" and "files are deleted after conversion" are claims about what happens to your file after it's already been sent. This page is about a different, checkable claim: that it's never sent at all.