Your PDF Converter Is Probably Uploading Your Files. Here's How to Check.

When you drop a PDF into a web-based converter, one of two very different things happens, and the interface almost never tells you which. Either the file is processed right there in your browser and never leaves your machine, or it is uploaded to a server somewhere, converted, and sent back. Both can produce the identical Markdown file. Only one of them means your document stayed private.

The good news is that you do not have to trust marketing copy to find out which one you're using. Your browser already ships with the tool that answers the question definitively. It takes about five minutes, works on any converter, and you should run it on the one you use now — including, to be fair, on MarkPrep. This post walks through exactly how.

Client-side vs. server-side, in plain terms

Server-side processing means the heavy lifting happens on someone else's computer. Your file is transmitted over the network to a backend, which runs the conversion and returns the result. Microsoft's MarkItDown, for instance, is a Python library that runs on a server; a hosted wrapper around it — such as markitdown.tech, whose own homepage describes a self-hosted server doing the work — necessarily receives your file to convert it. That is not an accusation; it is the architecture. If the conversion runs in Python on a backend, your file went to that backend.

Client-side processing means the conversion runs inside your browser tab, in JavaScript or WebAssembly, using your own device's CPU. The file is read from disk into the page's memory and transformed there. No network request carries the document anywhere. When you close the tab, it's gone, because it was never anywhere else.

The reason this distinction matters more than most privacy questions is that it is verifiable. You cannot see whether a server deletes your file after processing. You can see whether your file was sent to a server at all. The rest of this post is about the second thing, because it's the one you can actually prove.

Why "we delete after processing" doesn't settle it

Reputable server-side tools often promise they delete your files immediately after conversion. Take them at their word if you like — but understand what the promise can and cannot give you. It is a statement about what happens on infrastructure you cannot inspect, enforced by policies you cannot audit, retained in logs you will never see. There is no button you can press to confirm the deletion happened, no receipt, no way to distinguish a company that deletes on schedule from one that deletes eventually, or one whose backup snapshots keep a copy for ninety days, or one that got breached last Tuesday.

"We delete after processing" is a promise about the aftermath of an upload. Client-side conversion removes the upload, so there is no aftermath to make promises about. That is a categorically stronger guarantee: not "we handled your file responsibly," but "we never received it." And unlike the first, you can check the second yourself right now.

The audit: DevTools Network tab, step by step

Every major browser — Chrome, Edge, Firefox — has a Network panel that logs every request the page makes. If your file is being uploaded, it will show up here as an outbound request carrying roughly the size of your file. Here is the procedure.

1. Open your converter in a normal browser tab, but don't convert anything yet.
2. Open DevTools. Press F12, or right-click the page and choose Inspect, or use Ctrl+Shift+I (Cmd+Option+I on a Mac).
3. Switch to the Network tab. You'll see a table with columns for Name, Status, Type, and Size.
4. Clear the log using the circle-with-a-slash icon, so you start from a clean slate. Tick Preserve log if you want to keep records across any page navigations.
5. Convert your file. Pick a document you'll recognize by size — a 5 MB PDF is ideal, because a 5 MB upload is unmistakable.
6. Read the log. Sort by the Size column and look at the largest outbound requests. Click any suspicious row and check the request type (XHR/Fetch are the usual suspects for uploads) and the payload.

What you're looking for is a request that goes out carrying your file's worth of data. A genuine upload of a 5 MB PDF produces a request with a request body in the multi-megabyte range, headed to the converter's domain or a cloud storage endpoint. If you see that, your file left your machine. Full stop.

A useful sharper move: before converting, switch your Network throttling to a slow preset (the dropdown that offers "Slow 3G"). If the tool is uploading, a big file on a throttled connection will visibly crawl — you'll watch a progress bar or a pending request sit there for seconds. If conversion is instant regardless of how slow you set your connection, nothing is being transmitted, because there's nothing to wait for.

Reading the results honestly

Signs of server-side upload:

• A large XHR/Fetch/POST request with a request body roughly the size of your file.
• The request goes to an upload endpoint, an API route, or a cloud storage bucket.
• Conversion time scales with your network speed — throttle the connection and it slows down.

Signs of genuine client-side processing:

• No outbound request carries your file's payload. You may still see small requests for scripts, fonts, or a WebAssembly module — those are the app loading, and they flow inbound to you, not your document flowing out.
• Conversion works with the Network tab showing no relevant outbound traffic.
• It still works with your network disconnected entirely (more on that below).

The disconnection test is the blunt instrument that removes all doubt. Load the converter, then turn off your Wi-Fi or pull your network cable, then convert. If it works offline, the conversion is happening on your device, because there was no server to reach. A server-side tool simply fails here.

Now audit MarkPrep the same way

None of this is worth much if we ask you to exempt us from it, so don't. Run the exact procedure above on MarkPrep. Open the Network tab, convert a chunky PDF, and look for an outbound request carrying the file. You won't find one — the conversion runs in WebAssembly inside your tab, and the core rule the tool is built around is that no user document ever leaves it. Then pull the harder test: disconnect from the network and convert anyway. It works, because everything it needs is already in the tab. As a progressive web app, it will even install and run offline.

Two honest exceptions, both of which the interface labels rather than hides. First, converting a public URL does involve a network request — fetching a page from the web is, by definition, a network operation, and because browsers block cross-origin fetches, that request goes through a CORS proxy. That is a public web address you asked to retrieve, not a private document you dropped in. Second, optional OCR for scanned pages can use a key you bring yourself; if you enable that path, you're deliberately sending image data to a provider you chose, and you'll know because you turned it on. The default OCR runs locally via a self-hosted Tesseract build, entirely offline. Everything else — every PDF, Word doc, spreadsheet, and slide deck you convert — stays in the tab, and the Network tab will prove it.

When this actually matters

For a blog draft or a public research paper, upload away; the stakes are low. The calculus changes when the document isn't yours to leak:

• Legal contracts under NDA, where transmitting the text to a third-party server may itself breach the agreement you're trying to read.
• Patient notes and anything with health information, where regulations treat "we sent it to a vendor" as a reportable event.
• Financial records — statements, deal models, unpublished results — where the document's value is precisely that few people have seen it.
• Locked-down work laptops, where IT policy forbids uploading company files to unapproved services, and a client-side tool is the difference between doing your job and filing a request that takes three weeks.

In every one of these cases, "the converter probably deleted it" is not an answer you can bring to a compliance review. "The file never left the browser, and here's the Network log that shows it" is.

Run the audit on whatever you use today, then run it on us — convert a file with DevTools open and watch the Network tab stay quiet. When the document is one you can't afford to send anywhere, the right number of servers involved is zero, and now you know how to check.