Bank statement PDF privacy: what a statement reveals, and why converting without uploading matters

Published 19 October 2026 · by Tekiba

What a statement carries

Under European law all of it is personal data. The GDPR defines that as “any information relating to an identified or identifiable natural person”, and a statement names its person at the top. US financial privacy rules list the same contents among the information they protect; Regulation P's examples include “Account balance information, payment history, overdraft history, and credit or debit card purchase information”. And the FTC lists account numbers among what identity thieves take: “They might steal your name and address, credit card or bank account numbers, Social Security number, or medical insurance account numbers.”

What the rows imply

Financial data is not in itself one of the specially protected categories. The UK regulator says so plainly: “Whilst other data may also be sensitive, such as an individual’s financial data, this does not raise the same fundamental issues and so does not constitute special category data for the purposes of the UK GDPR.” But it adds that “it may still be possible to infer or guess details about someone that do fall within those categories”, and gives an example that a statement line could easily match: “you could reasonably infer health data from an individual’s list of appointments at an osteopath clinic or from an invoice for a series of physiotherapy sessions”. A monthly payment to a clinic, a place of worship, a union or a political party is a line on a statement like any other.

What the file holds beyond the page

A PDF is more than the picture of its pages. The PDF standard provides for document information: “A PDF document may include general information, such as the document’s title, author, and creation and modification dates.” On a downloaded statement that can include the software that produced the file and when it was made. The text layer that lets a converter read the table is also what lets anyone copy it out.

That matters if you try to hide something before sending the file. Drawing a black box over an account number in a viewer covers it on screen; Adobe lists “Text that is transparent, covered by other content, or matches the background color” among the hidden data a PDF can hold, and says of its own redaction tool that “Redaction removes only visible text and graphics. Hidden data, such as metadata or embedded content, must be sanitized separately.”

Where the copies go

A statement rarely stays in one place. It lands in a downloads folder, which may sync to a cloud drive; it may be emailed to a bookkeeper; it may be uploaded to a converter, and the result imported into accounting software. Each of those is a copy, held under the rules of whoever holds it: how long they keep it, who can read it, whether backups outlive a deletion. The FTC asks people to “think about what you do with documents or digital files that contain your financial information.”

A converter that works on a server needs a copy, because the file has to reach the server to be parsed there. That is a design, not a fault, and well-run services say what they do with it: where the file is processed, how long it is kept, and who else receives it. A policy that answers those in plain words lets you decide. The difference with a browser converter is simply that the copy is not made.

What converting in the browser changes, and what it does not

Browsers can read a file you choose without sending it anywhere. Mozilla's documentation puts it this way: “Using the File API, web content can ask the user to select local files and then read the contents of those files.” Sending a file to a server is a separate step that the page's code would have to take. LedgerDrop reads the PDF in the tab and builds the CSV there; it has no server that could receive a statement.

What it does not change:

• The files on your computer. The PDF and the CSV you save sit on your disk and in any folder that syncs.
• What the CSV carries. LedgerDrop's CSV has Date, Description, Amount, Balance and Check#. The statement's header — your name, address and account number — is not copied into it, but each description is kept as printed: every payee, every person you paid, and any name or account number the bank wrote into a transfer's description.
• What a QBO or OFX file needs. Those formats name the account, so LedgerDrop Pro asks for an account number, and offers to write only its last four characters.
• Analytics. The site counts usage with Google Analytics, which receives what a page view sends and a few fixed counters, never the file or its contents. The full list is on the privacy page.

How to see it in the network log

Every major browser records the requests a page makes. Open the log before you open the converter, because it only records while it is open; Chrome's documentation says “So long as DevTools is open, it logs all requests in the Network panel.”

1. Open the log. In Chrome or Edge, open DevTools and the Network panel and tick Preserve log. In Firefox, open the Network Monitor, where the setting is called Persist Logs: “When you select Persist Logs , the log is not cleared on page load.” In Safari, open Web Inspector's Network tab, which “includes API-driven network requests such as XHR, fetch , WebSocket , navigator.sendBeacon , etc.”
2. Open the converter and convert a statement. Watch what appears.
3. Keep every type of request in view. Filters such as Chrome's Fetch/XHR are a convenience, not a test: data can also leave in an image's address, a WebSocket message or a beacon, which the browsers list as types of their own. Look at where every request goes. Firefox's minus sign hides a destination you have already checked: “the query “-google.com” will show all requests that don’t have “google.com” in the URL.”
4. Open anything that goes elsewhere. Read its full address and its body — Chrome's Payload tab, Firefox's Request — and, for a WebSocket, its messages. Size proves nothing either way: a few rows of text make a small request.

On LedgerDrop you should see the page's own files from ledgerdrop.tekiba.app, the PDF library's worker pdf.worker.min.mjs from the same site when you first convert, and small requests to Google Analytics. You may also see a request to static.cloudflareinsights.com marked as blocked: the hosting provider adds that beacon, and the site's own policy refuses it, as the privacy page explains. Nothing else.

A log shows what happened this time. The site also carries a rule the browser enforces whatever the code tries: a Content-Security-Policy, whose connect-src lists the places a script may send to through interfaces such as fetch, XMLHttpRequest, WebSocket and beacons. Mozilla describes it: “The HTTP Content-Security-Policy (CSP) connect-src directive restricts the URLs which can be loaded using script interfaces.” LedgerDrop's names Google Analytics, the payment provider, and the licence service that turns a purchase into a key, with a test copy of it; it leaves out the site itself. That closes the ordinary routes, not every one: the policy still lets the page load images from its own address, and an image's address can carry text. So read the addresses of same-site requests in the log too, not only the outside ones. To see the policy, click the page request and read its response headers; the privacy page explains each entry.

What this page cannot tell you

What a particular online service does with a file once it has it; only its policy and its practice can. Nor can a network log protect a computer that is already compromised: software on the machine itself can read a file before any website does. And this is not legal advice on what you may share or keep.

Questions