About Pdf To Word

Drop in one PDF or up to 20 at once, up to 100 MB each, and every file comes back as a .docx. The default pass produces editable Word content: paragraphs joined back together, headings in Word's Heading 1-3 styles, bullet lists as real bullet lists, bold and italic where the source used them, and the page size and margins of the original so text wraps where it wrapped before.

A second mode puts every page in as a 150 dpi picture instead. That is the honest answer for a scan, and the useful one for a page whose layout matters more than its editability — a certificate, a form, a densely set table. You can also restrict a conversion to a page range such as 3-8, 12-, and choose whether each PDF page starts a new Word page.

The conversion runs on Mozilla's pdf.js parser and a .docx writer built for this tool, both inside your browser tab, in four steps:

1. Read. pdf.js hands back the glyph runs of each page with their coordinates and font ids. The real font behind each id — the difference between Georgia and Georgia-Bold — is resolved from the parsed font objects, which is what lets bold and italic survive at all.
2. Rebuild lines. Runs are grouped into visual lines by baseline, in the order the document emits them so a two-column layout is not interleaved. Gaps too wide for a single space become spaces the generator never wrote; a line ended after every table cell is stitched back into one row.
3. Infer structure. The document is measured — body text size, median line spacing, the left and right edges of its text column — and the structure is then read relative to those numbers rather than against fixed thresholds. That is how an 8 pt contract and a 24 pt slide deck both come out with their headings intact.
4. Write. The result is emitted as OOXML and packed into the .docx archive: a document part with the paragraphs and runs, a styles part carrying the heading definitions, a numbering part for the bullet lists, and any page pictures as embedded JPEGs.

No server takes part in any of it. The whole pipeline uses standard browser APIs, plus the pdf.js worker and character-map tables served from this domain.

Scans. There is no character recognition here. A page with no text layer holds nothing to read, so it is inserted as a picture rather than as text a recogniser might have got wrong. For the words out of a scan you need a converter that does OCR.

Tables. A table in a PDF is not marked as a table; it is text at column positions. Reconstructing Word table cells from those positions works until a merged cell or a wrapped line moves one, at which point the output is worse than plain text. So a row arrives as one line with its columns spaced apart, and you keep the option of converting that page as a picture instead.

Illustrations. Text mode carries text. A figure on an otherwise text-bearing page is not copied across — page-pictures mode is the way to keep it.

Your PDFs are never uploaded. Every step described above runs locally on your device — no file, filename, page image or extracted sentence is sent to a server, logged, or stored by Pdf To Word. A password typed to unlock an encrypted PDF is used for that and nothing else.

Because nothing is uploaded, the tool keeps working if you disconnect from the internet after the page has loaded; there is no round-trip to wait on in the first place. The one exception is a PDF set in CJK fonts, which fetches its character-map tables from this domain the first time one is needed. When you close the tab, navigate away or remove a file from the list, the in-memory copies of the PDF and the .docx are released — nothing is written to storage on your device, so nothing about them survives the visit.

This covers what Pdf To Word does with your documents, which is nothing beyond converting them for you to download. It says nothing about what a browser extension, a network proxy or the device itself might otherwise see.