Document conversion: Pandoc in the browser vs CloudConvert
CloudConvert is a polished, server-side conversion service supporting over a thousand format pairs. Its quality is good and the UX is smooth — every file you convert, however, passes through their infrastructure.
This site runs Pandoc via WebAssembly inside your browser. 14 input formats × 4 output formats. Nothing is uploaded, nothing is queued, nothing is stored — and there is no daily free quota.
| Browser Pandoc (this site) | CloudConvert | |
|---|---|---|
| File location | Stays on your device | Uploaded to servers for processing |
| Account / quota | None, unlimited | Free tier: limited conversions per day |
| Offline | Works after first load (PWA) | Requires network |
| Batch | Unlimited, client-side | Limited by plan |
| Format breadth | 14 inputs × 4 outputs (docx, odt, epub, html, csv, rst, latex, org, ipynb, …) | 1000+ format pairs |
| Fidelity | Pandoc WASM — same engine as CLI | Varies by conversion path |
| Price | Free | Free tier, then paid |
The privacy difference, concretely
Server-side converters must receive your document to convert it. For a public blog draft that is fine; for an NDA-covered spec or sensitive internal data it is a policy question you would rather not ask.
Browser conversion removes the question: the network tab stays empty while your file is parsed, converted and packaged locally.
When CloudConvert wins
Legacy binary formats: .doc, .xls, .ppt, Pages — Pandoc doesn't read these, and neither does any pure-WASM converter. You need LibreOffice or Microsoft Word to open them first.
Very large or damaged files: server-side LibreOffice-based pipelines can recover documents that strict parsers reject.
A middle path
For legacy .doc files, open in Word or LibreOffice and save as .docx first — then drop it here for a private Pandoc conversion. If a file is too damaged for client parsing, a one-off server conversion is a reasonable fallback — just know where the file goes.