Browser-based PDF tools: a privacy-first guide

Most online PDF tools work like this: you drop a file on the page, the page sends it to a server, the server processes it, and the page lets you download the result. Convenient. Also: your private documents passed through a stranger's machine.

For a vacation itinerary, that is fine. For a tax return, an HR letter, a medical bill, or a sensitive contract, it is less fine. The good news is that modern browsers can do most PDF work locally — no upload, no server. Here is how to find the tools that do that, and how to spot the ones that pretend to.

What "browser-based" actually means

A genuinely browser-based PDF tool runs the processing in JavaScript or WebAssembly inside your browser tab. Your file is read into memory by JavaScript, processed there, and offered back to you as a download. At no point does the file travel over the network.

An "online" PDF tool, by contrast, runs the processing on a server. Your file is uploaded, processed remotely, and the result is downloaded back. Even if the server promises to delete the file afterwards, the file still touched the server.

How to tell the difference

You do not need to take anyone's word for it. Browsers expose every network request the page makes. To check whether a tool is genuinely browser-based:

Open the tool's page
Open the developer tools (F12 on most browsers, or right-click and pick "Inspect")
Switch to the Network tab
Drop a file into the tool and run the operation
Look at the requests that appear

If you see a request that uploads your file (the request size will roughly match the file size), the tool is server-based. If you only see small requests for analytics, ads, or fonts — and nothing carrying your file's bytes — the tool runs locally.

What is possible in the browser today

Quite a lot. Open-source libraries like pdf-lib and PDF.js make most common PDF operations work entirely client-side:

Compressing PDFs (lossless cleanup)
Merging multiple PDFs into one
Splitting PDFs into pages or ranges
Rotating pages
Extracting pages as JPG or PNG
Reading metadata, page count, and structure

What is harder in the browser:

Deep image re-encoding inside PDFs (for maximum compression)
OCR on scanned PDFs (possible with Tesseract.js, but slow)
Complex form filling with cross-page validation
Reliable PDF-to-Word conversion (PDFs do not store paragraph structure)
Removing passwords from encrypted PDFs (legally murky and technically harder)

For these harder cases, desktop software like Adobe Acrobat is still the right tool.

What to look for in a browser-based PDF tool

The signals of a tool that takes privacy seriously:

It clearly states "files never leave your browser" or "no upload" — and the developer tools confirm it
It does not require an account or email signup to use
It does not impose arbitrary daily caps that nudge you toward a paid tier
It does not add watermarks to the output
It does not have intrusive interstitial ads or popups
Its privacy policy specifically addresses what happens to your files

Signals to be cautious about:

"Files deleted within 30 minutes" — this means the file is being uploaded
"256-bit SSL encryption" — this is just standard HTTPS, every site has it; not a privacy claim
Forced login or signup before processing
Aggressive upselling to a paid plan

Our take

The PDF tools at Fileoholic all run entirely in your browser. Compression, merging, splitting, PDF to JPG — none of it sends your file to a server. There is no signup, no daily cap, no watermark. The privacy claim is verifiable in your browser's developer tools, and the source is transparent about which library does which job.

For tasks browser tools cannot handle well (deep image compression, OCR, complex editing), we link out to desktop alternatives instead of pretending we can do them.

That is the privacy-first stack: do what is genuinely safe in the browser, and be honest about the rest.