Markdown Syntax to Word Formatting: The Complete Reference Guide

This guide covers how each Markdown element maps to its equivalent Word formatting when you convert a .md file to .docx. Use it as a reference when drafting in Markdown or when checking why a specific element isn't converting the way you expected.

Core Mapping Reference

The table below covers every common Markdown element and its Word output. A quality converter — like the one at mdtowordconverter.com — maps these to native Word constructs, not just visual approximations.

Headings in Depth

The # through ###### markers map to Word's Heading 1 through Heading 6 named styles. This matters beyond aesthetics.

When a converter applies the actual Heading 1 style (rather than just making the text large and bold), Word unlocks several structural features:

• Navigation Pane: Word's View → Navigation Pane displays headings as a document outline you can click through.
• Table of Contents: Insert → Table of Contents generates automatically from Heading styles — not from visually large text.
• Outline view: You can collapse and reorganize sections by dragging heading levels.
• Cross-references: Word's cross-reference dialog can reference a heading by its style.

A converter that outputs Normal style with a larger font size looks correct on screen but breaks all of the above. When evaluating a conversion, open the Styles sidebar and verify that heading paragraphs show "Heading 1", "Heading 2", and so on — not "Normal".

Lists in Depth

The difference between a native Word list and a text approximation is significant in practice.

A proper conversion creates <w:numPr> numbering properties on each list paragraph. This means:

• Numbers auto-update when you insert or delete items — no manual renumbering
• You can use Format → Bullets and Numbering to switch between bullet styles or numbering schemes across the whole list at once
• Multi-level lists indent correctly and maintain their hierarchy when you promote or demote items with Tab / Shift+Tab
• Word's list continuation logic works — pressing Enter inside a list item creates the next item; pressing Enter twice exits the list

A text-based approximation (where "1.", "2.", "3." are typed literally and bullets are hyphens) has none of this. It also creates accessibility issues because screen readers won't identify the content as a list structure.

If you've ever seen why numbered lists go italic in Word, the cause is usually a style conflict in the List Number paragraph style — something only possible because the list was converted as a native Word list structure.

Tables in Depth

A GFM pipe table converts to a native Word <w:tbl> element. The structural output includes:

• Header row: shaded background (typically a light gray), bold text, and a distinct bottom border
• Body cells: borders on all four sides for every cell
• Column widths: either distributed evenly across the page width or auto-sized to content, depending on converter settings

| Feature       | Supported | Notes                  |
|---------------|-----------|------------------------|
| Bold text     | Yes       | `<w:b/>` character run |
| Merged cells  | No        | GFM has no syntax for it |
| Nested tables | No        | Not in GFM spec        |

One important limitation: GFM tables are always simple grids. There is no Markdown syntax for merged cells (colspan or rowspan). If your source document requires merged cells, those need to be added manually in Word after conversion, or you need to work from an HTML source instead.

For deeper detail on why table conversion sometimes produces unexpected results, see why Markdown tables sometimes break in Word.

Code Blocks in Depth

Fenced code blocks (triple backtick syntax) and inline code map to different Word constructs:

Fenced code blocks should convert to a Code paragraph style with a monospace font. Some converters apply Word's built-in "Code" named style; others create a custom paragraph style. When the conversion is correct, the entire block appears in a monospace font (typically Courier New or Consolas), and many converters add a shaded background.

```python
def hello():
    return "world"

**Inline code** maps to the `Code Character` style, which applies monospace font inline within a regular paragraph — without starting a new block. This preserves the surrounding paragraph's line spacing, indentation, and paragraph style.

The distinction matters because character styles and paragraph styles interact differently with Word's style inheritance system. If you restyle the `Code` paragraph style, all code blocks update. The same applies to `Code Character` for inline code.

## What Markdown Doesn't Have a Word Equivalent For

Some Markdown or extended Markdown elements have no clean Word mapping:

**Strikethrough** (`~~text~~`) has no standard Word character style equivalent. Some converters skip it entirely; others create a custom character style or apply `<w:strike/>` directly in the XML. If strikethrough is important in your output, verify that your converter handles it before relying on it.

**Task lists** (`- [x] done`, `- [ ] todo`) have no Word equivalent. The GFM checkbox syntax is not part of the core Markdown spec, and Word has no native checkbox list style. Most converters output these as a regular bullet list with the literal text `[x]` or `[ ]` prepended.

**Footnotes** are not part of GFM. Pandoc-style footnote syntax (`[^1]`) is a Pandoc extension, not standard Markdown. Pandoc's converter does output proper Word footnotes (`<w:footnote>`), but most other converters don't support this syntax at all.

**Definition lists**, **abbreviations**, and **custom containers** are extensions that vary by Markdown flavor. None of them have standard GFM syntax, and none map to native Word elements.

## How to Verify the Mapping in Word

After converting, open the Styles sidebar:

- **Windows**: Home tab → Styles group → click the small arrow in the lower right corner
- **Mac**: Format → Style (or use the Styles pane in the sidebar)

Click into a heading paragraph. The Styles sidebar should highlight "Heading 1" (or "Heading 2", etc.) — not "Normal". Click into a list item: you should see "List Bullet" or "List Number". Click into a code block: you should see "Code".

If every paragraph shows "Normal" regardless of what it looks like visually, the converter is applying direct formatting rather than named styles. The document will look correct on screen but won't support TOC generation, Navigation Pane, or bulk reformatting.

This is one of the most reliable ways to evaluate conversion quality. A converter that produces proper named styles — like [mdtowordconverter.com](https://www.mdtowordconverter.com/tools/markdown-to-word/) — gives you a document that behaves like a real Word document, not just a visual copy.

## Try It and Check the Styles Sidebar

Paste any Markdown into the converter and download the `.docx`. Open it in Word, open the Styles sidebar, and click through the document. The named styles will tell you exactly how each element was mapped.

If you're working in the other direction — starting from a Word document and converting to Markdown — see the [Word to Markdown converter](https://www.mdtowordconverter.com/tools/word-to-markdown/) for the reverse workflow.