Word to PDF on iPhone

Finished files go to Safari's Downloads, which by default is the Downloads folder in Files on your device. From there you can move them into iCloud Drive, attach them to an email, or share them with any app through the standard share sheet.

The tool itself behaves identically regardless of what you are running it on. The same options, the same validation, the same progress reporting and the same output — a file produced on an iPhone is byte-for-byte equivalent to one produced anywhere else, because the same code does the work in both cases.

That consistency is worth something practical. Start a job on an iPhone and finish it on a different device, or hand the page to a colleague on another platform, and neither of you has to learn a different interface or account for a difference in behaviour.

The DOCX is parsed by Mammoth, which converts the document's XML into semantic HTML — headings become heading elements, lists become list elements, and so on. That HTML is placed in an off-screen container sized to A4's content width so line breaks fall where they will in the finished PDF.

The container is rendered to a canvas at 2x scale, then sliced into A4-page-height sections. Each slice is encoded as a JPEG and placed onto its own page with 20 mm margins. This slicing step is what produces correct multi-page output, and it is also why the resulting text is not selectable.

Your files are not uploaded. When you add a DOC or DOCX file, your browser reads it from your device into the memory of the tab you are looking at, and the word to pdf operation runs there using your own processor. Nothing is transmitted to any server at any point.

That means there is no file for anyone to store, no retention policy to trust, and no deletion schedule to take on faith. The document exists only in the memory of an open browser tab, and it is released the moment you close it, reload the page, or press start over.

The site uses standard anonymous analytics to count page views and how often each tool is used. Those events record which tool ran and whether it succeeded — never a file name, never file contents, and never anything that could identify a document or the person processing it.

No account is required, so no personal information is collected. There is no profile, no history and nothing tied to an identity, because no identity was ever created.

The strongest security property this tool has is structural: your file never travels anywhere, so there is no transmission to intercept and no server-side copy to breach. This is not a policy that could change — it is a consequence of where the code runs.

You can verify it in about thirty seconds. Open your browser's developer tools with F12, select the Network tab, and use the tool. You will see the page's scripts load — including the PDF libraries, which are fetched on demand the first time a tool runs — and then nothing further. No request carrying your document is ever made.

For a stronger test, disconnect from the network once the page has loaded. The tool will keep working exactly as before, which is only possible because nothing is being sent.

Uploaded files are validated in the browser before anything runs: the extension must match what the tool accepts, the file must not be empty, and it must be within the size limit. Malformed documents produce a clear error and a retry option rather than a silent failure.

Being clear about limits is more useful than a feature list that quietly omits them. Output pages are images rather than selectable text, page breaks are determined by height and can fall mid-paragraph, and headers, footers and complex layout features are not reproduced.

If you need capabilities beyond that — redaction, PDF/A conformance, OCR, or scripted batch processing across thousands of documents — dedicated desktop software genuinely earns its licence fee, and this is not trying to replace it. For the specific job of producing a PDF, everything you need is on this page.