Skip to main content
HerePDF

Guide

Client-Side vs Upload PDF Tools: What Happens to Your File

By Happy Turtle Tech · Published · Updated

Part of the topic PDF Privacy: What Leaves Your Device and What the File Reveals

At some point almost everyone has typed "merge pdf online" or "compress pdf free" into a search bar and clicked the first result, without thinking much about what happens next. For a flyer or a public form, that's fine. For a signed lease, a tax return, a medical referral letter, or a document with a client's personal details on it, it's worth twenty seconds of thought - because the results are a mix of two fundamentally different kinds of tool, usually with no indication of which is which, and most of them work in a way that hands your file to a stranger's server before you get anything back.

The two models, plainly

An upload-based tool sends your file to a server. The provider's infrastructure does the actual work - merging, compressing, converting - and sends a result back. This is how the majority of PDF websites have worked since the category existed, because it's also how most web applications in general are built: browser as a thin client, server as the workhorse.

A client-side tool does the opposite: it ships the processing code to your browser, and your browser does the work using its own JavaScript engine, without transmitting the file anywhere. This became practical at scale more recently, as libraries like PDF.js (for rendering and reading PDFs) and pdf-lib (for constructing and editing them) matured enough to handle real documents reliably inside a web page.

What happens when you "upload to convert"

A typical upload-based PDF tool works like this: your browser sends the full file to the provider's servers over the internet, a process there performs the operation, and the result comes back down to you. In between, your document exists on infrastructure you have no visibility into. It may sit in a temporary storage bucket, get written to logs by the web server or a CDN in front of it, be scanned by an automated content-moderation system, or be retained for some period under a terms-of-service clause about "improving our services." None of this requires bad intent from the provider - it's simply what happens by default when a file crosses a network boundary onto someone else's machine.

The provider's privacy policy might be perfectly reasonable. The problem is that you're now trusting a party you likely know nothing about - their security practices, their breach history, their staff's access controls, whether their "free" tier is monetized by scanning file contents. For most files, that trust is a small, acceptable convenience cost. For documents that contain financial details, medical information, legal terms, or anyone's personal data, it's a cost worth questioning.

What "runs in your browser" actually means

The PDF's bytes are read into your browser's memory, transformed there, and written back out as a new file - all without a single network request carrying the file's contents. Nothing needs to be "sent" because nothing needs to leave.

This isn't a claim you have to take on faith. Every browser ships a network inspector (usually under Developer Tools) that shows every request a page makes. Open it, load a client-side PDF tool, and process a file - you'll see the page's own code load once, and then silence while your file is worked on locally. If a tool actually uploaded your document, that request would show up plainly, with a payload size roughly matching your file.

Side by side

FeatureClient-sideUpload-based
Where your file goesNowhere - stays in your browser's memory for the duration of the operation.Sent over the network to the provider's servers, processed there, then returned.
What you need to trustOnly that the page's code does what it says - verifiable with a network inspector.The provider's security practices, retention policy, and staff access controls.
Works offlineYes, once the page has loaded. HerePDF also stores its own pages and code after one visit, so every tool keeps working with the network off.No - requires a live connection for every operation.
File size ceilingLimited by your device's available memory.Limited by the provider's upload cap and your connection speed.
Best suited forMerging, splitting, rotating, re-saving, converting PDF ↔ image - everyday operations.OCR at scale, AI summarization, cloud-sync workflows - work that genuinely needs a server.

What we measured: does HerePDF's merge send your files?

We wrote a script that does what the network inspector does, for every request, and ran it on HerePDF's own Merge. It builds two one-page PDFs for each run, each with a random 24-character marker written in the page text, in the title and in a plain comment, plus padding so a file is big enough to tell from ordinary page traffic. It opens the page in a fresh browser, declines the cookie banner, chooses the files, presses Merge, and checks that the download really is a two-page PDF holding both markers. Every request the browser makes is recorded, including the bodies of file uploads and WebSocket messages, and searched for the markers (as they are, URL-decoded, base64-decoded and decompressed) and for as many bytes sent as the two files add up to.

Nothing carrying the files left the page. We ran it on the built site and on herepdf.app. Both runs completed a real merge, and neither found a marker or a body the size of the files. After the files were chosen the page made 1 request, to its own host, and sent 0 bytes in it. Before any file was chosen it contacted 3 hosts: its own, and 2 analytics hosts, which the privacy page discloses and which are not given the file.

A check that never says yes proves nothing, so we tried it on uploads. The same script, pointed at a small server we control, reported an upload for each of 5 ways of sending a file: a multipart form upload, base64 in a JSON body, an upload made from a Web Worker, an upload made from a frame on another site, binary WebSocket frames. That is what the first version of the script got wrong: it missed the commonest, a multipart form upload, until we read request bodies at the level of the browser itself.

The limits: one browser, one anonymous flow and one day, so this is a measurement of what HerePDF's merge did when we ran it, not a promise about every tool and every future version. Seeing no request carry a file is evidence for that run, not proof that no copy was ever made, and we have not measured any other site: what an upload-based tool does is for its own policy to say. The file names are not published, only counts; the data and the method are there to check against, and the same check works on any tool with the inspector described above.

Questions worth asking before you upload anything

  • Does the tool say, in plain language, what happens to your file - not just "we care about your privacy," but the actual mechanism?
  • Does it need an internet connection to do the work? If disconnecting your device breaks the tool, your file is very likely leaving it.
  • Is there a retention or deletion policy, and does it describe a promise about someone else's server, or the simple fact that nothing was ever sent?
  • Would you be comfortable if this exact file appeared in a server log somewhere, even briefly?

Why upload-based tools still dominate

If client-side processing avoids an unnecessary privacy risk, it's fair to ask why most PDF sites still work the old way. Part of it is simple momentum - server-side tools existed first, and rewriting a working product is rarely a priority. Part of it is that a server which handles your file can also keep it, count its use or sell storage around it, which a page that never receives the file cannot. Neither reason is necessarily malicious, but neither is a reason to prefer that model as a user, either.

Where each approach is genuinely the right call

This isn't an argument that server-side processing is obsolete. AI-generated document summaries and workflows that need the result synced straight to cloud storage require real server-side computing - that's simply more work than a browser tab can take on. OCR sits in between: HerePDF's OCR PDF tool reads scans inside the browser, using your own device for every page, so a thousand-page archive is a long job for one tab and a server built for the purpose may suit it better. The distinction that matters is whether the task at hand actually needs a server. Merging, splitting, rotating, re-saving, extracting a page range or converting between PDF and image formats do not - which is exactly why they're a natural fit for running entirely on your own device.

Try the client-side approach

All twenty-seven HerePDF tools run this way - Merge PDF, Split PDF, Organize PDF, Edit PDF Bookmarks, Rotate PDF, Page Layout - N-up, Booklet, Poster, Compress PDF, Resize & Crop PDF, PDF to Image, Image to PDF, Extract Text from PDF, OCR PDF, Extract Images from PDF, Sign PDF, Fill PDF Form, Create Fillable PDF Form, Annotate PDF, Flatten PDF, Compare PDFs, Add Page Numbers, Header, Footer & Bates, Watermark PDF, Redact PDF, PDF Metadata, Remove Hidden Data, Check PDF Signatures, and Password Protect PDF - with nothing ever uploaded. Start with Merge PDF, the tool measured above, or read more about the site on the About page.

Frequently asked questions

If a site says "we delete your file after 24 hours," is that safe enough?

It means the file existed on their servers for up to 24 hours, was likely logged by their infrastructure provider, and its deletion depends on that specific promise being kept. For most everyday files that risk is acceptable. For anything you would not want a stranger to read, it is a risk worth avoiding entirely rather than trusting a policy.

Can a browser-based tool see or transmit my file without me noticing?

A malicious page could, if it wrote code to do so - client-side processing is a technique, not a guarantee, and it depends on the site actually not sending your data anywhere. You can verify it yourself with your browser's network inspector: watch for outgoing requests while the tool runs.

Is client-side always the better choice?

No - it depends on the task. For everyday operations like merging, splitting, rotating, or converting, client-side avoids an unnecessary upload. For tasks that genuinely need server-scale processing, such as OCR across a huge scanned archive, an upload-based tool built for that purpose is the more practical choice.

Did you check that HerePDF does not upload files?

Yes, for one flow and not for every tool: we merged two test PDFs in a real browser, on the built site and on herepdf.app, and recorded every request. Neither run sent the files or their contents anywhere; after the files were chosen the page made 1 request and sent 0 bytes. We have not measured any other site.