When you choose a file, your browser reads it locally using standard web APIs, the same ones for a CSV, an Excel file, or a PDF. The contents are handed directly to a program running inside that same browser tab, converted there, and the finished file is saved straight to your computer. They are never attached to a network request, never uploaded to a server, and this site has no backend to receive them even if it wanted to.
The tool uses a project called Pyodide, which compiles a real Python interpreter to WebAssembly so it can run inside your browser. Excel files are read with a library called SheetJS, and PDFs are read with Mozilla's pdf.js, both also running entirely client-side. None of this code performs network I/O with your data.
Open your browser's developer tools (F12 or Cmd+Opt+I) and watch the Network tab while you upload a file. No request containing your file's data will appear. You can even disconnect from the internet entirely after the page has loaded, then upload your file: it will still work, which is only possible if nothing is being sent out.
There's no database, no account, and no tracking cookies. Your statement and its transaction rows live only in this browser tab's memory and are gone the moment you close it. It is never sent to any server, and nothing is kept on your machine except the converted file you choose to download.
Some "private" tools still send a copy somewhere for one step or another. This one doesn't. There is no AI service in the loop, no sample upload, no telemetry on your file. From the moment you choose a statement to the moment you download the converted file, every byte of it stays on your machine. We do use privacy-respecting analytics to count visits and which buttons get used, but it never sees your statement, its contents, or even its filename, and there's no session recording.
fetch, XMLHttpRequest, or Python socket/requests calls
anywhere in it. Pyodide, pdf.js, and SheetJS each only make network requests once, on initial
page load, to fetch their own runtime/library files, never your data. PDFs have no real rows
or columns, just text positioned on a page, so pdf.js extracts each fragment's position and
the page reconstructs the table by grouping fragments into rows and snapping cells to columns
by their x-coordinates, then hands that to the Python parser. This works well for typical
text-based bank/card statement PDFs; it can't read a scanned image with no underlying text
layer, since there's nothing to extract. For those, a CSV or Excel export from the bank works.