The thing that surprises people about converting a document is that there is no page in the file to convert. A .docx holds paragraphs, styles and a note about the paper size, and the page you see on screen is produced by Word doing layout at the moment you open it. Any other program has to do that layout again, with its own fonts and its own line-breaking, which is why two converters give two different page counts from one file. Understanding that one fact explains every surprise in the output, including the one where a tracked deletion you thought was gone turns up in the PDF.
TL;DR: A .docx is a zip of XML carrying real structure, so headings, paragraphs and lists arrive correctly rather than being inferred. What does not arrive is the look: fonts, columns, tables, tab stops, numbering and exact spacing live in parts a converter has to implement a word processor to honour. Measured on real input, tracked deletions are dropped so an edited document reads as its final wording, a numbered list comes back bulleted, a table becomes its cells in reading order, and a tab becomes a space. Western European text renders; Cyrillic, Greek, CJK and emoji do not, because the built-in PDF fonts are WinAnsi. The Word to PDF converter does the typesetting in your browser.
What is inside a .docx?
A zip of XML parts, and one of them holds everything that matters here.
Open any .docx with an archive tool and you will find word/document.xml alongside a manifest, a relationships part, and usually styles, fonts, themes, numbering definitions and settings. The format is ECMA-376, with Microsoft's own implementation notes covering what Word does on top of it.
The document part is a sequence of <w:p> elements. Each one is a paragraph, with optional properties saying which style it uses and whether it belongs to a list, and inside it a series of runs carrying the actual text in <w:t>.
That is genuinely better than what a PDF offers. In a PDF a paragraph has to be inferred from the vertical gap between lines, which is where the conversion in the other direction loses columns and tables. Here a paragraph is a paragraph because the file says so, and a heading is a heading because the paragraph names a heading style.
The catch is in the parts a converter does not read.
Why does the result not look like it did in Word?
Because the look is spread across parts that amount to a word processor, and the converter typesets the text afresh instead.
The text is in the document part. The reason your text appears in Calibri at 11 point with 1.08 line spacing is in styles.xml. The reason your list reads "1., 2., 3." rather than "a., b., c." is in numbering.xml. The theme that supplies the heading colour is in another part again, and section properties govern margins, columns and page size per section.
Honouring all of it is building a layout engine with Word's semantics. What this tool does instead is read the structure and lay it out cleanly: Times Roman for body text, Times Roman Bold for headings, a 56 point margin, 1.4 line spacing, in the page size you choose.
So the output is a readable, correctly ordered document that does not look like the original. That is a real limitation and worth stating plainly rather than burying, because the people searching for this conversion fall into two groups and only one of them is served. If you want the text as a PDF that anyone can open, this is right. If you want that page, with its fonts and its spacing, keep reading to the section on Word's own export.
What survives the conversion?
Structure and reading order, reliably. Here is the full list, measured against the code rather than assumed.
| Element | Result |
|---|---|
| Paragraphs | Preserved, in document order |
| Headings | Preserved, sized by level, set bold |
| List items | Text preserved, marker replaced by a bullet |
| Table cells | Preserved as separate paragraphs in reading order |
| Tracked deletions | Dropped, as Word displays them |
| Tabs and line breaks | Become a single space |
| Bold, italic, colour, font | Not carried |
| Images | Not carried |
| Headers, footers, page numbers | Not carried |
| Footnotes and endnotes | Not carried |
The top half of that table is why this conversion is still worth doing: nothing in it had to be guessed. The bottom half is the price of not implementing Word.
What happens to tracked changes?
The deletions disappear, which is correct, and the fact that it needs saying is the interesting part.
A document edited with change tracking on keeps the removed text in the file, inside <w:delText> within a <w:del> element. Word knows not to show it as current text. A converter that walks every text node does not, unless someone thought about it.
Measured on a paragraph that originally read "The deadline is 31 March" and was edited to "30 April":
with the rule: The deadline is 30 April.
without the rule: The deadline is 31 March30 April.
Every version of that sentence anybody ever typed, run together, with no space between them. On a contract or an offer letter this is not a cosmetic bug: it publishes the negotiating history of the document to whoever receives the PDF.
Worth knowing for its own sake, whatever tool you use. If you are sending a converted document outward, check that a date or a figure you changed appears once rather than twice.
What happens to a numbered list?
It comes back bulleted, because the numbers are not in the paragraph.
A list paragraph carries <w:numPr>, which points at a numbering definition in another part. That definition holds the format, the start value, the indent levels and whether this list continues a previous one. The paragraph itself holds the text and nothing else.
So a converter reading only the document part knows the paragraph is a list item and not what marker it should carry. Rendering a bullet is the honest default:
• First point
• Second point
Ordinary paragraph
This matters when the numbers carry meaning. "See step 4" in a procedure, or a numbered clause in an agreement, loses its reference. If your document depends on its numbering, this conversion is the wrong one, and Word's own export is the right one.
What happens to a table?
The cells survive, the grid does not.
A table cell contains <w:p> elements like anything else, so the text arrives as ordinary paragraphs in reading order. A two column table of regions and figures comes out as:
Region | Q2 | EMEA | 412
Four paragraphs, one after another, with nothing recording that the first two were a header row. Carrying the table across means carrying column widths, row structure, merged cells and borders, then laying out a grid that paginates, which is a different and much larger tool.
This is the same trade in both directions. PDF to Word flattens a table because the PDF never had one; Word to PDF flattens it because rebuilding one is a layout engine. The honest advice in both cases: if the table is the point, screenshot it or keep the original.
Why did my tab-aligned layout collapse?
Because a tab is a position instruction, and without tab stops there is nowhere to send it.
<w:tab/> means "advance to the next tab stop", and the stops are defined in the paragraph's properties or inherited from its style. A converter that is laying text out with its own margins has no meaningful stop to jump to, so the tab becomes a single space. The same goes for <w:br/>:
input: Name <tab> Value <br> Next line
output: "Name Value Next line"
Anyone who built a two column list, a signature block or a simple table of contents with tabs loses the alignment entirely. It is one of the more common ways a converted document looks wrong, and it is invisible in the source: the file looks like ordinary paragraphs because that is what it is.
If alignment matters, a real table in the source document converts no better, but it at least fails more obviously.
Which characters can the built-in PDF fonts not render?
Anything outside Western European Latin, and the failure used to be silent about which character was at fault.
The PDF standard defines fourteen base fonts every reader has, and they are encoded with WinAnsiEncoding, a 256-character set documented in Annex D of the PDF specification. Using them means no font has to be embedded, which keeps the output small, and it means the alphabet is fixed.
Tested with pdf-lib, the library doing the drawing:
| Text | Result |
|---|---|
Quarterly report |
Renders |
"Revenue" rose, he'd said with curly quotes |
Renders |
| A sentence using em dashes, U+2014 | Renders |
Chiffre d'affaires réalisé en Août |
Renders |
Total: €1,249.50 |
Renders |
Отчёт за квартал |
Fails: WinAnsi cannot encode "О" (0x041e) |
Αποτελέσματα |
Fails: WinAnsi cannot encode "Α" (0x0391) |
季度报告 |
Fails: WinAnsi cannot encode "季" (0x5b63) |
四半期報告 |
Fails: WinAnsi cannot encode "四" (0x56db) |
Revenue up 🚀 |
Fails: WinAnsi cannot encode "🚀" (0x1f680) |
French, German, Spanish, Portuguese, Italian and the Nordic languages are fine, as are the euro sign, curly quotes and an em dash. Russian, Greek, Chinese, Japanese, Korean, Arabic, Hebrew, Hindi and every emoji are not.
The tool now names the character in the error rather than saying the document could not be converted, because "remove this character" is advice and "something went wrong" is not. A document in one of those scripts needs a converter that embeds a font covering it, which means a larger PDF and a different tool.
Why is a .doc file refused?
Because .doc and .docx are different formats that share three letters.
A .docx is a zip of XML, introduced in 2007. A .doc is a compound binary file in a layout dating to the early nineties, with the text interleaved among structures a parser has to walk. Reading one is not a variation on reading the other; it is a separate implementation.
So the converter checks the extension and says so, rather than failing on an unreadable zip:
| File | What it says |
|---|---|
.doc |
That is the older format. Open it and save as .docx first |
.rtf, .odt, .pages |
Not a Word document. Export as .docx |
.pdf |
Already a PDF; use the other direction for an editable file |
Opening a .doc in Word, LibreOffice or Google Docs and saving as .docx takes a few seconds and is a conversion those programs do well.
How are headings sized, and how deep do they go?
By level, bold, with everything past the third level treated as the third.
The style name is read from the paragraph and normalised, because both spellings exist in the wild. Word writes Heading1; several document generators write heading 1. Both resolve to the same level, and Title is treated as level one.
| Style in the file | Level used |
|---|---|
Title, Heading1, heading 1 |
1 |
Heading2 |
2 |
Heading3 |
3 |
Heading4 through Heading9 |
3 |
ListParagraph, BodyText, anything else |
Body text |
Three visual levels is a deliberate stopping point. A fourth level distinguishable from the third needs either another size step, which starts to collide with body text, or a weight or style change the base fonts do not supply.
How many pages will the PDF be?
Not the number Word showed you, and the difference is not a bug.
Line breaking depends on the font, so the same paragraph in Times Roman at 12 point occupies a different number of lines than it did in Calibri at 11. Margins differ. Line spacing differs. Everything that decides where a line ends has changed, so pagination changes with it.
In a measured run, a document of one heading and ten paragraphs of about forty words each laid out as two A4 pages: 39 lines on the first and 2 on the second, with the heading set at 20.4 point bold against 12 point body text.
The practical consequence is that page references break. "As described on page 7" in a converted document may now be page 6 or page 8. A document that cross-references its own pages should be exported from Word, where the layout is the one the references were written against.
When should you use Word's own export instead?
Whenever the appearance or the pagination is part of the content. That is a shorter list than it sounds, but the items on it matter.
| Use Word's export | Use a converter |
|---|---|
| A designed document: letterhead, CV, report with branding | A plain text document you need as a PDF |
| Anything with tables, images, headers or footers | Notes, an article, a draft, a transcript |
| Numbered clauses or cross-referenced pages | Any document where reading order is all you need |
| A document in a non-Latin script | A document you would rather not upload anywhere |
Word's File, Save As, PDF is a true export: the same layout engine that drew the page writes the PDF, so what you see is what you get. Nothing in a browser matches that, because nothing in a browser has Word's layout engine.
The case for converting at all is the last row of that table, plus not having Word to hand.
Why does this run in the browser?
Because documents are the most personal files people convert, and this conversion needs nothing a server has.
Reading a zip, parsing XML and drawing text are all things a browser does natively. The file is read from your disk into the tab, unzipped there, laid out there, written into a PDF there, and handed back as a download. No request carries the document and no copy is left anywhere.
The documents in question are contracts, CVs, medical letters, legal drafts and dissertations. The conventional alternative uploads them to a service, converts them on a machine you know nothing about, and keeps them for some period described in a policy nobody reads.
The limits are honest ones: Western European text only, no images, no formatting beyond headings and bullets. They are visible before you start rather than discovered afterwards, which is the trade worth taking when the alternative is a nicer-looking PDF of a document you no longer control.
