What a document carries, and what each conversion does with it
A .docx is a ZIP of XML files, and most of what makes it a document is not the text. There are styles — named definitions like Heading 1 that many paragraphs share — and there is direct formatting, where someone selected a line and pressed bold. They look identical and behave completely differently under conversion: a style survives as a style, a direct-formatted run survives only as the formatting it produced. Alongside those sit numbering definitions, tracked changes, comments, footnotes, headers and footers, text boxes, embedded fonts and document properties, each stored separately from the paragraph text.
List numbers are the clearest example. Word does not store "1." as text; it stores a reference to a numbering definition and works the number out while drawing the page. Text extractors that walk the paragraph XML therefore drop every number and hand you an unnumbered list. DOCX to TXT rebuilds them instead — "1.", "1.1", "a)", "iii." — including lists that restart or continue across the document.
Tracked changes and comments are a decision, not an accident. A document under review holds both the deleted text and the inserted text, in the same file, marked up. DOCX to TXT reads it as though every change were accepted: insertions kept, deletions left out. Comments are not included at all, which is usually what you want when the plain text is going somewhere public. Footnotes and endnotes come through as [1] markers with the notes collected at the end, headers and footers can be switched on, and text boxes appear once each in reading order rather than being repeated or lost.
What a conversion to PDF fixes is pagination. In a word processor, where page four ends is recalculated every time the file opens, using the fonts and printer driver of whoever opened it — which is why a document arrives with the table split across two pages at the recipient's end and not at yours. A PDF has no such recalculation: the page breaks were decided once, at conversion, and are now a fact about the file. Word to PDF, ODT to PDF and RTF to PDF get those breaks from a full word-processor layout engine rather than from a browser approximating one, which is why text boxes, shapes, headers and footers land where the author put them.
What it loses is editability and reflow. Styles become visual formatting, the outline becomes bookmarks, and the text no longer rewraps to a phone screen. Fonts embedded in the document are used as they are; a font that is neither embedded nor installed on the engine is replaced by its closest metric-compatible match, so lines still break in the same places even though the letterforms differ.
Ebooks have no pages to preserve. EPUB, MOBI and AZW3 are reflowable — the reader app decides where each page ends, at whatever font size you chose — so "page 40" is not a property of the book, and the pagination in your PDF is created at conversion from the page size and margins you pick. What is in the file is the chapter structure and the contents list, and those become real PDF links and bookmarks. AZW3 carries a stylesheet and often embedded fonts, so it comes out looking like the publisher designed it; old MOBI files have no stylesheet at all, which is why a converted MOBI looks plainer than the same book in the Kindle app — the app was adding typography the file never contained.
RTF is text all the way down, which is why it survives decades of software. Its catch is character encoding: RTF predates Unicode and stores text in old code pages — Central European, Cyrillic, Greek, Japanese — which is where the mojibake in badly converted RTF comes from. Each is decoded properly here, alongside modern Unicode text.
Where a browser is genuinely the wrong tool
Some of these tools run entirely on your device and some do not, and it is worth being exact about which. PDF to Text, TXT to PDF, DOCX to TXT, HTML to DOCX and Markdown to HTML are pure browser tools — the file is read, converted and written inside this tab, and nothing is sent anywhere. Word to PDF, ODT to PDF, RTF to PDF, HTML to PDF, Markdown to PDF and the three ebook converters use a conversion engine on our server, because reproducing a word processor's page layout, or paginating a book properly, is not something a web page can fake. What is sent differs: Word, ODT and RTF documents go as they are, while Markdown files and ebooks are unpacked and turned into a web page in your browser first, and it is that assembled page which is sent. Either way it travels over an encrypted connection, is converted, and is deleted the moment your download is ready — nothing is stored, logged or shared. Each of them also has an in-browser fallback if the engine is unreachable, and tells you when it has used it and what the fallback could not keep.
Formats we do not open. Legacy binary .doc files from Word 97–2003 convert fine on Word to PDF, because the server engine reads them directly — but the browser-side DOCX to TXT cannot, and wants a .docx. Password-protected documents need the password removed in the program that set it. DRM-protected Kindle books cannot be opened by any converter anywhere — that is what the protection is for — and neither can Amazon's newer KFX format, which only the Kindle app reads.
Long-document work. Master documents, cross-reference fields, indexes, automatically generated tables of authorities, mail merge and citation managers are word-processor features, and a converter is not a word processor. Install LibreOffice — it is free, it reads every format on this page, and for these jobs it is simply the right program.
Batch and automation. These tools run when a person clicks. Converting a thousand files on a schedule is a command-line job, and the free tools are the same engines: LibreOffice in headless mode converts anything Writer can open, Pandoc moves between Markdown, HTML, DOCX, LaTeX and a dozen other formats with more control than any web form, and Calibre handles ebooks in bulk and converts between every unprotected ebook format there is.
Faithful layout in the other direction. Turning a heavily designed PDF back into an editable document is an inference problem, not a conversion, and nothing does it perfectly — not us, not the expensive desktop products. If the original document still exists, edit that.
Choosing between the tools that sound alike
Markdown to PDF vs Markdown to HTML. Same parser, different destination. Markdown to PDF gives you a paginated document with a typeface, page size and margins you choose, headings as PDF bookmarks and a contents list that jumps to the right page — for printing, attaching or archiving. Markdown to HTML gives you either a standalone styled page or a bare snippet for pasting into a CMS — for publishing. If you want Markdown in Word, go through Markdown to HTML and then HTML to DOCX.
Word to PDF vs ODT to PDF vs RTF to PDF. The same engine underneath; they differ only in what you feed them. Word to PDF for .docx. ODT to PDF for anything from LibreOffice, OpenOffice or a Google Docs "Download as OpenDocument". RTF to PDF for WordPad, TextEdit and the letters and reports business systems still emit. Picking the page that matches your extension matters less than you would think — what matters is that none of them is TXT to PDF, which has no formatting to preserve in the first place.
TXT to PDF vs Markdown to PDF. TXT to PDF sets your text as text: one typeface, your margins, no interpretation. Markdown to PDF reads the # and the * as instructions and produces headings, lists, tables, highlighted code and a bookmark outline. Feed a Markdown file to TXT to PDF and you get a PDF of the asterisks.
EPUB, MOBI and AZW3 to PDF. All three accept more than their name suggests, so any of them will open your file; the pages differ because the books do. EPUB and AZW3 (KF8) carry stylesheets and often embedded fonts, and come out looking designed. MOBI is the older container with minimal formatting, and its converted PDF is deliberately plain. If a Kindle file contains both layouts, the newer one is used.
HTML to DOCX vs Markdown to HTML. HTML to DOCX renders the markup with your browser's own engine first, so resolved CSS — fonts, sizes, colours, spacing, borders — is written into the document as real Word formatting, with Word heading styles, real lists and real tables rather than boxes pinned in place. Markdown to HTML produces the markup in the first place. Neither runs JavaScript, ever.
DOCX to TXT vs PDF to Text. Both hand you plain text and they are reading very different things. A .docx still knows what a paragraph, a list and a table are, so DOCX to TXT can rebuild list numbers and keep table rows together. A PDF knows only where each character was painted, so PDF to Text infers lines and paragraphs from position — good, and never as structurally faithful. If you have both the original document and a PDF of it, extract from the document.
DOCX to TXT vs saving as .txt from Word. Word's own plain-text export drops list numbering, mangles tables and has opinions about encoding. DOCX to TXT rebuilds the numbering, writes tables either as tab-separated rows that paste into a spreadsheet or as aligned columns that stay aligned even in Chinese and Japanese, and saves UTF-8 with the line endings you ask for.