Think about what people actually convert to PDF: employment contracts, medical intake forms, tax returns, lease agreements, divorce paperwork, bank statements for a mortgage broker, a photograph of a passport for a visa application, a signed offer letter, insurance claims.
That is, almost by definition, the most sensitive paperwork a person handles. And the standard way to convert it is to upload it to a website you found through a search result.
What “uploading” means in practice
When you use a server-side converter, your file:
- Travels across the internet to that company’s infrastructure.
- Is written to storage, such as a disk, an object store or a queue.
- Is opened and processed by software running on their machines.
- Is written back to storage as output.
- Is served to you as a download.
- Is deleted, at some point, according to their policy.
Each of those steps is a place where the document exists in a form somebody other than you could read. That is no accusation of bad faith. It is the architecture, since server-side processing requires the server to have the file.
What the policies actually say
Read a few and the phrasing is consistent:
“Files are automatically deleted from our servers after 1 hour.”
“We do not access, copy or analyse your files.”
“All uploads are encrypted in transit and at rest.”
These are probably true. They are also promises about behaviour and give no guarantee about capability, and the distinction matters:
- You cannot verify any of them. There is no way to confirm from outside that deletion happened, or that nothing was logged.
- “Deleted” is doing quiet work. Deleted from the primary store, or from backups too? Backups routinely persist for weeks.
- Encryption at rest protects against disk theft and does nothing against the service itself, which necessarily holds the keys.
- Policies change, and companies get acquired. Your file was uploaded under the old terms.
- Breaches happen to careful companies. A promise not to look at your data is not a promise nobody else will.
- Many services run on infrastructure they do not own, and the policy usually permits sharing with those subprocessors.
None of this makes server-side converters illegitimate, and plenty are run responsibly. It means the trust is unverifiable, and for a document containing your salary, your medical history or your passport number, unverifiable is a real cost.
The specific risks worth naming
Regulated data. If you handle documents covered by HIPAA, GDPR, attorney-client privilege or similar, uploading them to a third-party converter may itself be a compliance problem, regardless of what happens to the file afterwards. Many organisations prohibit it in policy, and many people do it anyway because the convenient tool is a search away.
Metadata. Documents carry more than their visible content: author names, edit history, tracked changes, and in scanned images the EXIF data from the camera, sometimes including GPS coordinates of where the photograph was taken.
Identity documents. A passport or driving licence photograph is the most valuable single file for identity fraud, and should be the last thing anyone uploads casually.
How browser-based conversion differs
Modern browsers can do this work themselves. They parse documents, decode images and construct PDFs, in JavaScript, on your machine.
A browser-based converter downloads the code to your device and runs it there. Your file is read from your disk into the page’s memory, processed locally, and handed back to your downloads as a local blob URL.
The file never travels, because there is no endpoint on the other side to receive it.
This replaces a promise with the absence of any need for one. There is no retention policy because there is nothing retained, no breach risk because there is no store, and no subprocessor question because there is no processing off your machine.
How to check for yourself
Don’t take this on faith either. Two tests take under a minute each.
The network tab: open your browser’s developer tools (F12 or Cmd+Option+I), go to Network, and run a conversion. On a client-side tool you will see the page’s own assets load and then nothing further, with no request carrying your file. On a server-side tool you will see a large POST as it uploads.
The offline test: load the page, then disconnect from the internet by turning off wi-fi or enabling airplane mode. Then convert. If it still works, the processing is happening on your machine, because nothing else is available. This one is conclusive.
Both tests work on any converter, including this one. Run them.
The trade-offs, honestly
Client-side conversion has limitations:
- Fewer formats. Some require decoders too large to ship to every visitor. HEIC, legacy .doc and RAW image formats are the common casualties.
- Your machine’s limits apply. A very large batch may struggle on a phone where a server with more memory would not.
- No server-side extras. OCR, heavy compression and format-specific rendering engines are genuinely easier server-side.
For the everyday operations (images to PDF, documents to PDF, merging, splitting, reordering) none of those limits bite, and the privacy difference is absolute.
Practical guidance
- Check before uploading anything sensitive. Run the offline test.
- Prefer client-side tools for contracts, medical records, tax documents and identity papers. There is no reason to accept the risk when the alternative exists.
- Check your organisation’s policy if this is work paperwork.
- Strip metadata where it matters. A format conversion generally does this as a side effect of re-encoding.
- Don’t email sensitive documents unencrypted either. Email is stored on several servers along the way and is the more common leak.
Everything on this site (images to PDF, Word to PDF, merge, split, organize) runs entirely in your browser. Test it offline and it will still work. What we do and do not collect is set out in full in the privacy policy.