How to Test Word Formatting Preservation, Feature by Feature

Most Word-to-Markdown comparisons run many tools across a variety of documents. This method inverts that: you build one carefully constructed test document and score each converter you are considering, feature by feature. The document includes every Word feature that commonly fails in conversion: H1-H4 headings, bulleted and numbered lists with deep nesting, tables (simple and merged-cell), images with captions, code blocks with syntax highlighting, footnotes, in-text citations, equations, and cross-references. Per-feature scoring shows exactly where each converter holds up and where it breaks, which is more useful than an aggregate score when you pick a tool by the features you actually need.

Build the test document

Construct one synthetic document that exercises every common Word feature you rely on. A checklist of sections, with suggested amounts:

• Title page with subtitle and author
• Table of contents (auto-generated by Word)
• Section 1: H1 with H2 and H3 subsections, normal paragraphs, bold/italic/underline
• Section 2: Bulleted list (3 levels of nesting), numbered list (3 levels of nesting), mixed list with bullets and numbers at different levels
• Section 3: Three tables; a simple 4-column table, a table with merged horizontal header cells, a table with multi-row headers and merged vertical cells
• Section 4: 5 inline images with captions, 1 large full-width image, 2 images placed side-by-side
• Section 5: 4 code blocks (Python, JavaScript, bash, SQL) with proper Word "Code" style applied
• Section 6: 12 footnotes throughout, 8 in-text citations using Word's bibliography feature, 3 cross-references to other sections (e.g., "see Section 3.2")
• Section 7: 6 equations; 3 inline, 3 display
• References section: full bibliography (10 entries) generated from Word's reference manager

Converters to compare

1. Pandoc
2. MDisBetter (web tool)
3. Word2MD.net (paid tier with AI alt text)
4. Mammoth.js
5. Word native HTML export → html2md (the "do it yourself" baseline)

Write down the version of each converter when you run the test. The Word HTML baseline is there to show how much a dedicated converter adds over the path you already have: Word's native HTML export is famously bloated, with inline styles, MSO-specific tags, and font declarations everywhere.

Scoring

Score each feature 0-5: 5 = preserved exactly, 3 = preserved with minor degradation, 1 = preserved with significant loss, 0 = dropped or broken.

The scoring sheet

Make one row per feature and one column per converter. The rows to include:

• Headings: H1, H2, H3, H4, each scored separately
• Inline formatting: bold / italic / underline
• Lists: bulleted (1 level, 3-level nesting), numbered (1 level, 3-level nesting), mixed numbered + bulleted
• Tables: simple, merged horizontal cells, multi-row headers with merged vertical cells
• Images: inline images, captions, side-by-side images, alt text
• Code: code blocks with a language, code blocks without one
• Academic: footnotes (as GFM footnotes), in-text citations, cross-references, inline equations, display equations, bibliography section
• Document structure: table of contents

That is 26 rows, so a maximum of 130 points. Keep per-category subtotals as well: a converter that loses points on academic features can still be the right pick if you never use them.

Reading the sheet by the features you care about

If headings + lists + simple tables matter most

Weight those rows. If several converters score full marks there, pick on convenience: MDisBetter for zero install, Pandoc for the command line and batch jobs.

If footnotes, citations, equations matter most

Weight the academic rows heavily, put enough footnotes and citations in the test document to be representative, and make sure Pandoc is in the comparison.

If image alt text matters most

Score alt text separately from image extraction. A converter either carries over the Word alt text as it is (often empty or generic) or, in tools with AI alt text such as Word2MD's paid tier or Hyperleap AI, generates a description. Add those tools to the comparison if this row decides your choice.

If complex tables matter most

Check which strategy each converter uses on merged cells: repeating the value, emptying the extra cells, or falling back to a raw HTML <table> with rowspan/colspan. The HTML fallback is the most faithful and the least portable. Whatever the strategy, plan to fix the most complex tables by hand.

If code blocks matter most

Score code blocks with and without a language separately: a converter can keep the block and still drop the language hint.

What Markdown cannot represent

Three features that no converter can carry over cleanly, because the format itself lacks them:

1. Side-by-side images: Markdown has no image floating syntax, so images come out one after the other.
2. Cross-references: Word's "see Section 3.2" feature loses its dynamic link in Markdown. Expect plain text.
3. Multi-row headers + merged vertical cells: GFM doesn't support these. Even an HTML fallback only partially helps because not every Markdown renderer respects rowspan.

For docs heavy in any of these features, plan for manual cleanup regardless of which tool you use, and don't let these rows dominate the comparison.

Re-run the sheet over time

AI alt text is the newest row on this sheet. When you re-run the test, check again which converters offer it and at what price, and note converter versions so the new scores are comparable with the old ones.

How to test on your own documents

A synthetic document shows you each feature in isolation. Your real docs combine them in their own way. To confirm the result:

1. Pick one of your real, representative Word docs: ideally one that includes the features you actually care about
2. Convert it through 2-3 candidate tools (don't bother with the Word HTML path)
3. Open the .md outputs side-by-side with the Word original
4. Score each on the features that matter to your workflow (skip features you don't use)
5. Pick the tool that wins on your weighted score

Within 30 minutes you have data from your own corpus. Generic rankings point in a direction; your own documents give you the answer for your use case.

What about other source formats?

Most workflows mix Word with PDF and URL. Same logic applies: pick the right converter per format. See best free PDF to Markdown converters for PDF and best URL to Markdown tools for web. Cross-format pipelines often end up with a mix: Pandoc for Word, marker for PDF, Trafilatura for URL, or one platform like MDisBetter for all four formats.

Score output cleanliness too

Beyond raw feature preservation, the cleanliness of the resulting Markdown source matters for ongoing editing. Add a second, smaller sheet that scores each converter on source readability:

• Line wrapping: hard-wrapped lines are fine for reading but produce noisy diffs in Git. Pandoc lets you turn wrapping off with --wrap=none.
• Trailing whitespace: invisible in a preview, noisy in a diff.
• Empty paragraphs: runs of blank lines left over from Word spacing.
• Stray HTML: raw HTML for complex tables may be a deliberate fallback; MSO-specific HTML never is.

Time it if volume matters

Conversion speed isn't usually a concern for one-off use, but matters for batch jobs. If it matters to you, time each converter on your own test document. Count what you actually wait for: web tools include upload, processing and download time, while local tools skip the upload but need to be installed first.

Where to start

Reasonable starting points for your shortlist: Pandoc for complex docs (academic, legal, technical with footnotes/citations/equations), Word2MD for image-heavy docs going into AI workflows, MDisBetter for convenience and multi-format breadth, Mammoth.js for developer integration, and Word's native HTML export as the baseline to beat. Then let your own scoring sheet decide. See also how to benchmark Word to Markdown converters, best Word to Markdown tools, and Word tables to Markdown guide.