Why convert files in your browser instead of uploading

The default model: upload, process, download

Type "convert PDF to EPUB" into a search engine and almost every result on the first page asks you to upload your file. The site picks it up on its servers, runs a conversion library against it, and offers the result back as a download. From a usability standpoint, the model is fine — the user doesn't need anything installed, the server has plenty of CPU, and the result arrives in seconds.

The trouble is that "your file" stops being yours the moment it leaves your machine. The operator now has a copy. So do whatever logging, backup, and analytics systems they run. And so does anyone who later compromises that infrastructure. For a public-domain ebook this is meaningless. For a contract, a medical bill, a tax form, a manuscript, or a folder of personal photos, it's a stack of risks that the convenient interface doesn't surface.

The real risk isn't theoretical

In March 2025 the FBI's Denver field office issued a public warning, echoed by Malwarebytes and TechCrunch coverage, that free online file-converter sites had become a significant malware vector. The model in the wild: legitimate-looking conversion sites that did perform the conversion but also bundled malware into the downloaded result, or scraped sensitive content out of uploaded documents (cryptocurrency seed phrases, financial records, social security numbers) for follow-up scams. The FBI's specific advice was to be skeptical of any free online converter and to prefer tools that don't require uploading.

That's separate from the routine risks every honest upload-based site carries: misconfigured S3 buckets, logging that retains files past stated policies, third-party data brokers that get a sliver of metadata, and the simple reality that "deleted after one hour" is a promise nobody can independently verify.

What changed: WebAssembly and Canvas

For most of the web's history, doing real work inside a browser was impractical. JavaScript was slow, browsers couldn't read binary file formats efficiently, and the libraries that did the heavy lifting (image decoders, PDF parsers, OCR engines) were native code that ran on servers. Browser-based file conversion existed but was limited to toys and small text formats.

Two shifts changed that. The first was WebAssembly, shipped in 2017 and now supported by every modern browser. Wasm lets compiled C, C++, or Rust code run inside the browser at speeds within a couple times of native. That made it practical to compile real libraries — pdf.js (Firefox's own PDF engine), Tesseract (Google's OCR engine), libheif (the HEIC decoder), JSZip, pdf-lib — and run them client-side. The second shift was that browsers grew the APIs needed to read and write binary files locally: the File API, FileReader, Blob, the Canvas 2D context, OffscreenCanvas, and the URL.createObjectURL trick for downloads. Combined, these let you build a full conversion pipeline that never sees the network.

Performance: how it actually feels

The performance trade isn't what people expect. Server-side conversion has effectively unlimited CPU but a network round-trip; a 50 MB PDF spends most of its conversion time uploading and downloading. Browser-side conversion has zero network cost but is bounded by your device. The crossover is somewhere around "a recent laptop." On a Mac M-series or a current Windows ultrabook, browser conversion of a couple-hundred-page PDF, a batch of HEIC photos, or a moderate EPUB takes seconds — comparable to a server round-trip on a typical home connection.

On phones, browser conversion is slower than a server, mostly because mobile CPUs are conservative on Wasm and RAM is tight. A 200-page PDF that converts in 4 seconds on a laptop might take 20 seconds on an iPhone. For most users that's still acceptable, and for sensitive files the time cost is worth not handing the file to a stranger.

What you should never upload to a converter

A short list of files that should never go to an upload-based converter regardless of its reputation:

• Contracts, NDAs, and legal documents with party names and financial terms.
• Medical records, lab results, EOBs, and anything covered by HIPAA in the US or equivalent regimes elsewhere.
• Tax returns and W-2s.
• Bank statements and any document showing account numbers.
• Government IDs (passport scans, driver's licenses).
• Manuscripts and IP you haven't yet published, especially anything subject to a publishing or employment contract.
• Customer data, employee data, or anything covered by your employer's data-handling policy.
• Cryptocurrency seed phrases or recovery sheets. (Yes, people scan these into PDFs. Don't upload them anywhere.)

For everything in this list, browser-based conversion is the right answer — or, for irreplaceable files, a desktop tool like Calibre, ImageMagick, or pdftk that doesn't touch the network at all.

How to verify a converter doesn't upload

The benefit of browser-based conversion is that it's externally verifiable. You don't have to trust the operator's privacy promises; you can watch the network and confirm directly.

• The DevTools method. In any modern browser, hit F12 (Cmd-Option-I on Mac), open the Network tab, then run the conversion. The only requests you should see are for the page assets (HTML, CSS, JavaScript libraries) and analytics or ad calls — never anything carrying your file's payload as a request body.
• The airplane-mode method. Load the converter page on Wi-Fi, then turn the Wi-Fi off (or unplug the ethernet cable). Run the conversion. If it still works, the file isn't going anywhere — the conversion is happening on your machine. This site is built to pass this test on every converter page.
• The Content Security Policy header. Look at the network response headers for the converter page. A strict CSP that doesn't allow connect-src to arbitrary domains is structural evidence the page can't exfiltrate your file even if its code wanted to.

Where the browser model breaks down

Browser conversion isn't always the right answer. A few cases where the upload model is genuinely the better tool:

• Huge files. A 4 GB raw video or a 1000-page color PDF will struggle in a browser tab. Desktop software handles those better.
• Format support depth. Niche formats (some CAD exports, old TeX flavors, obscure ebook variants) don't have mature Wasm libraries. A server can run anything.
• Pipeline jobs. If you're converting thousands of files as part of a workflow, scripting it against a server API is more practical than dragging files into a tab.

For everyday personal use — converting an EPUB, processing a folder of HEIC photos, getting text out of a scan — browser-based tools are now strictly better for any file that should stay private.

Where to go from here

All the converters on FreeBookConvert run in your browser using the model described above. If you'd rather start with format background, see What is an EPUB?, HEIC explained, or JPG vs PNG vs WEBP vs HEIC. For the OCR side specifically, see How OCR actually works and the tools at PDF OCR, Scanned PDF to Text, and Make PDF Searchable.