Why Numbered Lists Go Italic in Word When Converting from Markdown

You converted a Markdown ordered list to Word. You open the .docx and the numbers — 1, 2, 3 — are in italics. Or the entire list item text is italic even though you never wrote *italic* anywhere near the list. Or the numbers look visually different from the paragraph text next to them in a way that's hard to explain.

This is not a random rendering glitch. It has a specific, reproducible cause, and it comes down to one thing: whether your converter uses real Word list numbering or fake text numbering.

The Bug

The symptom presents in a few different ways depending on the converter:

• The "1." "2." "3." number characters appear italic while the list item text is normal weight
• The entire list item — number and text — is italic, even though the source Markdown has no italic markup on those lines
• The list renders fine visually in isolation, but when there is any italic paragraph immediately before the list, the list items pick up the italic formatting

All three variations share the same root cause.

Root Cause: Literal Text Numbers Instead of Native Numbering

Most Markdown-to-Word converters handle ordered lists by converting them to plain paragraphs that start with the number as typed text. Your source Markdown:

1. First item
2. Second item
3. Third item

Gets converted to three paragraphs in the Word document, each one starting with the literal characters "1. ", "2. ", "3. " as part of the paragraph text. The converter applies the Normal paragraph style (or no explicit style at all), and moves on.

The problem is that paragraph formatting in Word is inherited. When a paragraph has no explicit character formatting set on its runs (the XML elements that hold inline text), it inherits from the paragraph style. If the surrounding document context has active italic formatting — and with many converters, it does, because they fail to explicitly reset character formatting between elements — the number characters inherit that italic state.

This is why italic text immediately before a list is such a reliable trigger. The converter processes the italic paragraph, sets italic on, processes the next element (the list), and never turns italic off for the number runs.

The Deeper Root Cause: Fake Numbers vs. Native Word Lists

Word's document format — OOXML (Office Open XML), the XML schema that .docx files are built on — has two completely different ways to represent a numbered list, and they do not behave the same way.

The first way is a paragraph that starts with typed text: "1. First item". The "1." is just characters in the paragraph. Word has no idea this is a list. It is a Normal paragraph that happens to start with a digit and a period.

The second way uses a <w:numPr> element (short for numbering properties) attached to the paragraph. This tells Word: "This paragraph is item N in list definition X." Word generates the number itself, manages the indentation, and tracks the sequence. The number is not part of the paragraph text — it is produced by Word's list engine.

When a converter creates fake numbered paragraphs instead of native <w:numPr> list paragraphs, two things break:

1. The number characters sit inside the paragraph's text runs and inherit whatever character formatting is active on those runs — including italic
2. The paragraph style applied is usually Normal instead of List Number or List Paragraph, which means none of Word's built-in list formatting (indentation, spacing, numbering sequence management) applies

With native <w:numPr> numbering, the number is generated by Word and has its own independent character properties. Italicizing the list item text does not make the number italic. Content above the list does not affect the number's appearance. The number is structurally separate from the paragraph text.

The Markdown That Triggers the Bug

Here is the exact pattern that reliably produces italic numbers with broken converters:

*This is an italic paragraph introducing the list.*
 
1. First item
2. Second item
3. Third item

In a converter that uses fake text numbering and does not explicitly reset character formatting between block elements, the italic state set by the *...* paragraph carries over into the number runs of the list items. The "1." "2." "3." appear italic in Word even though nothing in the Markdown source marks them as italic.

The list item body text may or may not be italic depending on whether the converter resets formatting before writing the text run. The number is almost always affected because it is written first, before any formatting reset logic runs.

What Correct Output Looks Like

When a converter handles ordered lists correctly, the numbered list in Word has these properties:

• Each list item paragraph has a <w:numPr> element referencing a numbering definition, not a "1. " prefix in the text
• The paragraph style is List Number or List Paragraph, not Normal
• The number is rendered by Word's numbering engine, independent of the paragraph's character formatting
• Italicizing any amount of text above, below, or within the list has no effect on the numbers
• The list is a real Word list: it auto-renumbers if you add or remove items, and it responds to Format → Bullets and Numbering

How to Check Whether Your Converter Used Native Numbering

Open the converted .docx in Word. Right-click on one of the list item paragraphs and choose Paragraph. Look at the Style field at the top of the dialog.

If it says List Number, List Paragraph, or any style in the List family, the converter created a native Word list. The numbered paragraphs are real list items.

If it says Normal — and the number is part of the paragraph text, not a separate element — the converter used fake text numbering. The formatting inheritance problem is present, and the italic bug is possible whenever italic content appears near the list.

You can also check by pressing Tab at the end of the last list item. In a native Word list, Tab indents the item and creates a new list item at the same level. In a fake numbered paragraph, Tab just inserts a tab character.

Quick Fixes If You Are Stuck With Broken Output

If you have already converted a document and the numbers are italic, select all the list items in Word. In the Styles pane (Home tab, Styles group), apply List Number. This re-assigns the paragraph style and may clear the italic inheritance depending on how your document template is configured.

If the style change does not fix it: select the affected list items, then go to Format → Bullets and Numbering (or use the numbered list button in the Home tab ribbon) and apply a numbering format. This forces Word to create native <w:numPr> numbering on the selected paragraphs and removes the literal "1. " text.

These are manual repairs. If you are converting Markdown regularly, doing this after every export is not a viable workflow.

The Long-Term Fix: Use a Converter with Native List Support

The only permanent solution is to use a converter that generates real <w:numPr> list elements instead of fake numbered paragraphs.

mdtowordconverter.com uses the docx JavaScript library to construct Word documents directly from the parsed Markdown AST. Ordered list nodes are mapped to native Word list paragraphs with proper <w:numPr> numbering properties and List Number paragraph styles. The converter explicitly manages the numbering definition and list indentation — italic content before or after the list has no effect on the numbers, because the numbers are not in the paragraph text at all.

This is the same approach described in how to convert Markdown to Word without losing formatting — direct AST-to-OOXML mapping, no HTML intermediate, explicit formatting on every element.

This Also Affects Nested Lists

The same root cause produces worse results with nested lists. A converter using fake text numbering handles nesting by adding spaces or tab characters in front of the literal "2. " prefix, creating the visual appearance of indentation. But there is no multi-level list structure, no <w:numPr> with a level attribute, and no connection to Word's outline numbering system.

The result is that nested list formatting — "1.1", "1.2", "a.", "i." — either does not appear at all (because Word has no idea these are sub-items) or appears inconsistently. And the same italic inheritance problem applies at every level of the fake nest. For documents with complex multi-level numbered lists, this failure compounds quickly.

Native <w:numPr> numbering supports up to nine list levels, each with its own number format and character properties. Converters that use it correctly produce multi-level lists that behave exactly as expected in Word's multilevel list controls.

Convert Without the Italic Bug

If your numbered lists are coming out of Word with italic numbers or unexpectedly italic text, the converter you are using is writing literal text numbers instead of native Word list elements. The fix is a converter that builds real OOXML list structures.

mdtowordconverter.com handles ordered lists natively — paste your Markdown, download the .docx, and the numbered list will have correct, non-italic numbers that behave like any list created directly in Word.

For similar root-cause debugging on other formatting failures, why Markdown tables break in Word covers the same underlying pattern applied to table conversion.