Word to HTML: How to Convert Documents Without the Formatting Garbage

Anyone who has tried to publish a Word document on the web has encountered this problem. You open a DOCX file in Word, click Save As, select Web Page, and get an HTML file that weighs 10 times more than it should and contains code that looks like it was written by a machine having a breakdown.

A simple one-page document with a heading, three paragraphs, and a bulleted list produces HTML with dozens of proprietary mso-prefixed styles, XML namespace declarations, font declarations for fonts you never chose, and enough inline CSS to style an entire website. Paste this into your CMS and you get formatting conflicts, broken layouts, and text that refuses to match your site's design.

The good news: you do not have to use Word's HTML export. There are better ways to get from a Word document to clean, semantic HTML.

Why Word Produces Terrible HTML

Word is a print layout program. When you format a document in Word, you are defining how ink should appear on paper: exact font sizes in points, precise paragraph spacing in centimeters, tab stops at specific positions, page margins that affect text reflow. Every one of these print-specific properties gets translated to an inline CSS style when you save as HTML.

A heading that you formatted as Heading 2 in Word does not simply become an h2 tag. It becomes a paragraph tag wrapped in a span with inline styles specifying the font family, font size (in points, not a web-friendly unit), line-height, font-weight, color, margin-top, margin-bottom, and sometimes a dozen other properties. The actual semantic meaning of the heading is buried under formatting noise.

On top of that, Word inserts XML namespace declarations (xmlns:o, xmlns:w, xmlns:m) for Office, Word, and Math features. It adds conditional comments targeting Internet Explorer. It includes a full CSS block defining styles like MsoNormal, MsoListBullet, and other Microsoft-specific class names that no web browser uses or needs.

The result is an HTML file where the actual content might be 2 KB but the formatting overhead pushes it to 20 KB or more. And none of that extra code does anything useful on the web.

What Clean HTML Looks Like

Here is the same content as clean HTML:

<h2>Project Summary</h2>
<p>The Q3 results exceeded expectations across all regions.</p>
<ul>
  <li>Revenue up 12% year over year</li>
  <li>Customer retention at 94%</li>
  <li>Three new enterprise accounts signed</li>
</ul>

No inline styles. No proprietary classes. No XML namespaces. Just semantic tags that describe what the content is (a heading, a paragraph, a list), not what it should look like. The visual styling comes from your website's CSS, which means the converted content automatically matches your site's design.

This is what you want from a Word to HTML conversion. And it is what you get when you use the right tool for the job.

Five Approaches to Clean Conversion

Approach 1: Dedicated Word to HTML converter. The fastest path from DOCX to clean HTML. You can convert Word documents to clean HTML by uploading your file and getting stripped, semantic HTML output. Dedicated converters parse the DOCX file structure directly (it is XML inside a ZIP archive) and map Word's styles to HTML semantic elements. Heading 1 becomes h1, Heading 2 becomes h2, Normal paragraph becomes p, and list items become proper ul/ol with li elements. Inline styles and Microsoft-specific markup get stripped.

Approach 2: Copy from Word, paste into a rich text editor, switch to HTML view. Many CMS platforms (WordPress, Drupal, Joomla) have rich text editors that accept pasted Word content and attempt to clean it up. The results vary. WordPress's classic editor does a decent job stripping Microsoft-specific markup when you paste. Other editors are less thorough. After pasting, always switch to the HTML/source view to check for leftover span tags and inline styles.

Approach 3: Google Docs as an intermediary. Upload the DOCX to Google Docs, which strips out Microsoft-specific formatting. Then copy from Google Docs into your CMS or use a Google Docs to HTML exporter. This produces cleaner output than Word's direct HTML export, but Google Docs adds its own inline styles and class names that also need cleaning.

Approach 4: Pandoc command-line conversion. For developers and anyone comfortable with the terminal, Pandoc converts DOCX to HTML with excellent semantic mapping:

pandoc document.docx -t html5 -o output.html --wrap=none

Pandoc produces clean HTML5 with semantic elements. It handles headings, lists, tables, links, and images correctly. It does not add inline styles or proprietary markup. For batch processing, you can script Pandoc to convert an entire folder of DOCX files.

Approach 5: Manual cleanup with regex. If you already have Word's HTML output, you can clean it with find-and-replace patterns. This is the tedious approach, but sometimes it is the only option when working with existing HTML files.

Common regex patterns for cleaning Word HTML:

Remove all inline styles:  style="[^"]*"
Remove all class attributes: class="[^"]*"
Remove empty spans: <span>([^<]*)</span> replace with $1
Remove mso comments: <!--\[if.*?\]>.*?<!\[endif\]-->

After regex cleanup, you still need to convert div and span structures to semantic elements manually. This works for occasional cleanup but is not sustainable for regular conversions.

The Span Soup Problem

The single most annoying artifact of Word's HTML export is nested spans with inline styles. A sentence where one word is bold produces something like this: a normal span wrapping the regular text, then a separate span with font-weight:bold wrapping the bold word, then another span for the text after it. Sometimes Word nests three or four spans deep for text that has multiple formatting attributes (bold, italic, a different color).

In clean HTML, that same sentence is one p tag with a strong element around the bold word. Two tags instead of eight. No inline styles anywhere.

Dedicated converters handle this collapsing automatically. They recognize that a span with font-weight:bold should become a strong tag, a span with font-style:italic should become an em tag, and everything else can be stripped. The result is lean, readable markup.

What to Check After Conversion

Even good converters need a quick review pass. Here is what to look for:

Empty tags. Paragraphs that contained only whitespace or formatting in Word sometimes convert to empty p or div tags. These add unwanted spacing in the rendered page. Remove them.

Heading hierarchy. Word documents sometimes jump from Heading 1 to Heading 3, skipping Heading 2. This creates accessibility issues and confuses screen readers. Fix the heading hierarchy so it flows sequentially: h1, then h2, then h3.

Link targets. Hyperlinks in the Word document should convert to a tags with proper href attributes. Check that the URLs are correct and complete. Relative links that pointed to other documents in the same folder may need updating for the web.

Image references. If the Word document contained images, verify that the img tags point to accessible image files. You may need to upload the extracted images to your web server and update the src attributes.

Table structure. Simple tables usually convert well. Tables with merged cells, nested tables, or mixed content cells may need manual adjustment. If a table was used for layout rather than data, consider replacing it with CSS flexbox or grid.

CMS Publishing Workflow

The workflow that produces the best results for regular web publishing is:

1. Write and format the document in Word using styles (Heading 1, Heading 2, Normal, List Bullet) instead of manual formatting
2. Convert the DOCX to clean HTML using a dedicated converter
3. Paste the clean HTML into your CMS's HTML/source editor
4. Switch to visual mode to verify the content looks correct
5. Upload and link any images that were in the original document

The key step that most people skip is step 1: using Word styles instead of manual formatting. When you select text and manually set it to 18pt bold instead of applying the Heading 2 style, the converter has no way to know that text was meant to be a heading. It can only see a paragraph with large bold text. Using styles gives the converter the semantic information it needs to produce proper h2 tags instead of styled paragraphs.

If you inherit documents from other people who did not use styles, a dedicated converter with good heuristics can often guess the intended structure from formatting cues. But it is always a guess, and reviewing the output for correct heading levels and list structures is worth the two minutes it takes.

Word documents and web pages are fundamentally different formats. One is designed for fixed-layout printing, the other for flexible-layout screens. Conversion between them always involves interpretation. The goal is not pixel-perfect reproduction of the Word layout in a browser. The goal is clean, semantic markup that your website's CSS can style correctly, that search engines can parse efficiently, and that screen readers can navigate properly. A good converter gets you 90 percent of the way there. The last 10 percent is a quick review and minor adjustments.