Word to Markdown Converter

How Word to Markdown conversion handles a page format

A DOCX stores document structure, relationships and media in an OOXML package. Markdown stores a much smaller set of ideas: headings, paragraphs, emphasis, links, lists, code, simple tables and, in some readers, footnotes. This converter follows that boundary deliberately. Heading styles become headings; numbered and bulleted paragraphs become lists; hyperlinks remain links when their URL scheme is safe; notes become linked definitions. Font size alone is not guessed into a heading, and page coordinates are not presented as semantic structure.

The conversion runs in a lazy browser worker. First the package is inventoried independently: paragraphs, list paragraphs, tables, notes, relationships, revisions, comments, headers, footers, merged cells and image crops. A semantic DOCX reader then projects the main document to safe HTML, and the same conservative engine used by the HTML to Markdown converter turns that projection into Markdown. The independent inventory is why a feature that does not fit Markdown can still appear in the report rather than disappearing without a trace.

Images are exact package bytes, not a screenshot of Word

Every embedded image used by the converted story receives a stable path such as assets/image-001.png. The bytes and SHA-256 recorded in conversion-report.json come from the DOCX package entry itself. If the same package image is reused, its path is reused. If two entries have the same hash, the report records the duplicate relationship without inventing different pixels.

That narrow promise matters. Word can display a crop, rotation, recolor, shadow, shape mask or other effect without rewriting the stored image. The converter keeps the source bytes and reports crop evidence, but it does not claim to reproduce Word’s rendering engine. For a dedicated inventory and fresh crop workflow, use extract images from Word document. Externally linked pictures are not downloaded: they are references, not bytes inside the file, and local processing must not quietly make a network request.

Tables, lists, footnotes and tracked changes

A rectangular table without merged cells maps naturally to pipe Markdown. A cell with rowspan or colspan does not. Such a table stays as sanitized HTML inside the Markdown document, which CommonMark permits, and the report says why. Flattening the merge into a pipe grid would look clean while shifting the meaning of cells; preserving safe HTML is the more accurate result.

List semantics come from Word numbering properties, not from a bullet glyph copied out of the page. Mixed and nested lists can therefore survive when the DOCX exposes their structure. Number restarts are carried by the semantic conversion where representable, but Markdown renderers commonly renumber ordered lists; inspect a restart when its exact visible numeral is legally or editorially important. Footnotes and endnotes become stable reference definitions. Safe hyperlinks in the body and notes are kept.

Tracked changes use the document’s current view: inserted text is included and deleted text is omitted. Comments are review metadata and are inventoried rather than inserted into prose. Header and footer stories are counted but not spliced between body paragraphs. Text-box content can move into reading order because Markdown has no page position. Equations and embedded objects without a verified text projection are reported as loss. These are explicit conversion policies in the JSON report, not hidden implementation accidents.

The verified ZIP is the portable result

The download contains document.md, conversion-report.json and every referenced local asset. Before the browser offers it, the ZIP writer hashes each input, writes a STORE archive, reopens the central directory, reads every entry and compares its CRC, size and SHA-256 with the intended bytes. The report itself is deterministic: the same source bytes, source name, converter version and options produce the same ordered structure, hashes, policies and findings.

When a document has no local images, you can also download the Markdown alone. When assets exist, use the ZIP. A rich clipboard copy cannot carry stable filesystem paths after it leaves this tab, so the page does not offer a styled-copy button that would appear to work and then leave broken images behind.

For a text-only conversion, continue in the Markdown editor when headings or prose need revision. Keep the conversion report as the evidence boundary: editing can improve the result, but it does not retroactively prove omitted comments, revisions or page layout were preserved.

Word paste and Google Docs belong to the rich clipboard route

If the source is a selection already open in Word or Google Docs, paste it into the HTML to Markdown converter. Browsers expose clipboard flavors such as text/html and text/plain; that page reads HTML first and shows a receipt naming Word, Google Docs or generic rich HTML when the markup carries recognizable evidence. It also reports Word list styling that exists only in CSS, inline data images, remote image URLs and clipboard-only image references.

Google Docs now has native Markdown capabilities, including copying or downloading document content as Markdown in supported workflows. A separate “Google Docs to Markdown” upload route would either duplicate the rich clipboard feature or imply access to a private Google document that this local, account-free page does not have. The search demand is real; the honest product answer is a guide and a hardened paste path, not a second converter with an address field.

Local processing and evidence limits

The selected DOCX is transferred directly to a worker in this tab. No POST or PUT request contains the document, and the converter does not fetch linked images. Unsafe or duplicate paths, damaged entries, excessive entry counts and pathological declared compression ratios are rejected before conversion; these are structural corruption and ZIP-bomb boundaries, not a total document-size quota. File-size advice appears before conversion rather than rejecting a legitimate large document merely because it exceeds a convenient marketing limit.

The semantic DOCX reader is Mammoth 1.12.1, used under its BSD-2-Clause license. It is bundled with this site and loaded only after a file is selected; no third-party script or conversion service receives the document.

The conformance suite for this route uses deterministic OOXML documents generated locally and checks their package relationships, Markdown, report and output ZIP. Microsoft Word itself and native Word or Google Docs clipboard access are not available in the test environment. The DOCX fixtures prove the documented package contract, while rich-paste tests use synthetic browser DataTransfer flavors; neither is a claim that every Word version’s visual layout or desktop copy gesture has been reproduced. That distinction is also why the page promises semantic Markdown and exact stored assets, never pixel-perfect Word rendering.