Which PDF conversions stay on your device, and which two leave it
· 7 min read
Most PDF conversions run in your browser; two send data out. The per-conversion trust table, the exact OCR trigger, and a 5-step pre-convert check.
A secure PDF converter earns the label the same way any tool does: you can see exactly what happens to your file. On this site, most conversions run as JavaScript inside your tab, so the bytes never leave your machine. But two paths do send data out: scanned PDF pages that need text recognition, and the HTML-to-PDF tool, which renders pages through a third-party API. This guide names each conversion, states what leaves on each path, and gives you a short check to run before you convert.
The table below rests on reads of the shipped source from 12 October 2026, plus vendor and reference pages for the two server paths. Where something could not be confirmed (how vendors handle received data, how password-protected files behave, how accurate handwriting recognition is), it is marked UNVERIFIED and kept out of the verdict. If you want the architectural reason uploads matter at all, start with why no-upload PDF tools exist; this post is the per-conversion version of that argument.
How to check a file before you convert it
Work through these five steps in order. They route every file to the right path before anything leaves your machine.
- Check for a text layer. Open the PDF, select all, copy, and paste into a plain text editor. If paragraphs arrive intact, the file has embedded text and the PDF-to-Word text path will handle it locally. For a command-line version, run
pdfinfo(which, per its man page on mankier.com, "prints the contents of the 'Info' dictionary (plus some other useful in[formation…]") alongsidepdftotext: an empty text output against a normal page count means a scan with no text layer. The same man page documents password flags, a reminder that a password keeps casual readers out without scrubbing anything. - Decide whether OCR will fire, and how sensitive the file is. Nothing selectable means the OCR fallback will fire for those pages, and page images will travel to a server-side model endpoint. This is the step where sensitivity matters: a scanned contract, medical record, or client file sends its pixels out, while the same file with a born-digital text layer converts fully locally. Sensitivity only changes the answer on the OCR path, so do not let a scanned file scare you off the local conversions.
- Note handwriting. Print recognition degrades on unusual fonts and layouts; handwriting degrades further (UNVERIFIED: no accuracy figures were sourced for this guide, so expect manual cleanup without a number attached). A sensitive file that is also handwritten is the strongest do-not-convert-here case: the pixels leave and the result still needs review.
- For HTML-to-PDF, check the URL, not a file. A public marketing page is a reasonable input. An intranet page, a signed preview link, or any URL carrying session tokens or personal data in its query string is not: the URL string plus its contents pass through the vendor, and pages behind logins may not render usefully either. For anything authed or internal, your browser's Print-to-PDF stays fully local and is the better tool.
- Word-to-PDF, merging, and splitting: proceed. All three are verified local, as the table shows, so no checklist branch is needed beyond knowing the files stay in your tab. The companion guide on why no-upload PDF tools exist covers the architecture behind that promise.
The trust table: which conversions stay local and which two leave
One line first: text stays; pictures travel; URLs are shared. Each row gives the verdict, what leaves, and the exact trigger.
| Conversion | Stays or leaves? | What leaves, and when |
|---|---|---|
| PDF to Word, pages with a text layer | LOCAL | Nothing leaves. The tool opens the file with pdf.js, reads embedded text items per page, and builds the Word file in your tab. Any page you can select and copy from takes this path. |
| PDF to Word, scanned pages (OCR fallback) | SERVER, per page | A rendered picture of each textless page. The trigger is exact: only pages where that page has zero extractable text items take this path — a born-digital page never does, a scanned page always does, and a mixed file splits page by page so only its scanned pages leave. Each such page is painted to a canvas at viewport scale 2, serialized to a JPEG data URL, and sent to a server-side Genkit flow (imageToTextFlow) served by a Google model endpoint, with the API key held server-side. |
| Word to PDF | LOCAL | Nothing leaves. The tool converts with the in-browser mammoth library (the JS mammoth package used client-side, per its upstream project page) plus jsPDF, which generates PDFs client-side per its project page. No server call exists in the convert path. |
| HTML to PDF | SERVER, every use | The URL string, not file bytes. Your input is forwarded by a server action to the third-party conversion API at api.pdflayer.com, which fetches the page with its own infrastructure, renders it, and returns PDF bytes; the vendor states on its homepage that it creates PDFs "from URLs & HTML" and that resulting documents "are stored using a lightning-fast CDN". No local path exists for this tool. |
| Merge and split PDF | LOCAL | Nothing leaves. Both operations build the result with pdf-lib in your tab, with zero network calls in the path; the page thumbnails are canvas renders for display only and are not transmitted. |
Two footnotes keep the table honest. First, the standalone image-to-text OCR tool shares the exact custody profile of the OCR row above: same server-side flow, triggered on every use, since the payload is an image by definition. Second, no separate PDF-to-text converter tool was found; text extraction is the local half of the PDF-to-Word path (the same embedded-text read), so a "PDF to text" row would duplicate row one. Try the conversion itself on the PDF to Word converter for ordinary files, the Word to PDF converter where you need the fully local direction, or the HTML to PDF converter for public URLs, with the warnings in each row attached.
A note on rendering detail: the OCR path paints pages at viewport scale 2 before serializing (scale 2 over the standard 72-point base works out to roughly 144 dpi by arithmetic, shown here as arithmetic rather than as a sourced specification). Do not read a DPI figure into it.
Pixels vs text: why the two server paths differ
Text extraction reads the manifest; server OCR mails a photograph. A born-digital PDF already contains its words as embedded text items, and reading them resembles copying from a reader: the browser transmits nothing because there is nothing to look at. That is why a file with selectable text converts with zero exposure: the operation is a parse, not an upload.
The OCR fallback is a different act. When a page has no embedded text, the tool paints the page to a canvas and serializes it with the canvas method that, per MDN's canvas documentation, "returns a data URL containing a representation of the image in the format specified by the type parameter": a data:image/jpeg string sent to the server flow, as MDN's broader canvas reference describes the underlying element. The recipient gets pixels: layout, stamps, signatures, marginalia, and everything visible on the page, not just the words. A scan with black-box overlays transmits the underlying pixels as rendered. Treat it with the same caution as any image upload.
The HTML-to-PDF path inverts the question. Your document never uploads, because there is no document: the tool sends the URL string (plus render settings such as page size and margins) to the pdflayer API, whose own systems fetch the page, render it, and store the result on its CDN. The exposure is that the vendor learns exactly which URL you converted and when, the target server sees a fetch from vendor infrastructure, and anything behind the URL travels through a third party. Different paths, different questions: pictures travel, URLs are shared, parsed text stays.
What to do instead on the two server paths
For a sensitive scan, do the recognition somewhere the pixels never leave: your operating system's built-in OCR, a desktop app that runs offline, or a scan-to-text step before you open any converter. Then bring the recognised file back to the PDF to Word converter through its local text path. Keep the original scan offline throughout. The image-to-text OCR tool is convenient for ordinary images and shares the server profile. Use it where the content is boring, never where it is sensitive.
For a sensitive or authed page, skip HTML-to-PDF entirely and use your browser's Print-to-PDF: open the page normally, print, choose Save as PDF. The whole job stays in your tab with no vendor in the loop, and login-gated content renders as you see it rather than as a third-party fetch sees it. Reserve the HTML to PDF converter for public, uncredentialed URLs. For everything else (merging, splitting, compressing, Word-to-PDF), the PDF merger and splitter and the PDF compressor are confirmed local, so privacy-cautious readers can keep working without changing tools.
Limits: what this guide does not promise
Password-protected files get one line: the converter source surfaces a generic "files might be encrypted" error string, but no password prompt or unlock behaviour was confirmed in the converter paths (UNVERIFIED), so a locked file may simply fail conversion. Complex layouts are a fidelity limit, not a trust issue: the text path groups extracted items by vertical position and flattens them into paragraphs, so tables, columns, and footnotes may reflow. Converted-output contents were not byte-inspected, so custody claims here cover transmission only (whether bytes left your tab), not what the output file contains. And nothing here characterizes vendor data handling beyond the data path: what leaves, to whom, in what form. How long any recipient keeps inputs or outputs was not verified and is not stated.
Related Tools & Further Reading
- PDF to Word Converter — the tool whose two paths this guide separates; check the OCR row before converting scans.
- Word to PDF Converter — the fully local direction; a safe default for shareable outputs.
- HTML to PDF Converter — for public, uncredentialed URLs only; authed pages belong in Print-to-PDF.
- Convertio Alternative — the cloud-converter comparison for readers weighing ToolSura against Convertio-style services.
Written by
Ahmed Zaki
My framing question is always what has to survive the conversion, because a PDF has no single correct output. To Word, the hard part is structure rather than glyphs. A PDF stores the positions of characters that have already been drawn, so the extractor has to reconstruct paragraphs, lists and tables from coordinates. It gets this right most of the time for prose and rarely for tables, because a table is a grid of positioned fragments and no reliable signal says which fragments belong together.
To HTML you have a choice that matters more than the converter you pick. Render the page as an image and you get a perfect visual match with no selectable text and no accessibility. Extract the text and you get selectable, accessible, reflowable output that will not look like the original. Trying to get both is the real project.
To images the decision is resolution. Rendering at screen density looks sharp on a screen and soft in print. Rendering at print density produces files nobody wants to email. I cover the scale factor and what it does to file size.
Fonts are the recurring cause of mangled output. A document using a font the converter does not have gets substituted, and the substitution changes metrics, which reflows the page. There is no universal fix, but there is a check: compare the page count before and after. Everything here runs locally, and I say so on every page, because a document leaving a device is the thing people most want to avoid when the file contains what the filename suggests it contains.