Word to HTML: Turn a .docx Into a Clean Page You Can Send and Track

Plenty of work still starts in Word: onboarding guides, policies, client reports, statements of work. Word to HTML is the step that turns one of those files into a page someone opens from a link, on a phone or a laptop, with nothing to download. Done carelessly, the result is bloated, oddly styled and missing its images. Done properly, you get clean semantic HTML, or a page HTMLvault builds from the .docx itself and serves behind a link you can track and keep current.

Why Word's "Save as Web Page" falls short

Word can export HTML itself (File > Save As > Web Page). The output is written so Word can open it again, not so a browser renders it cleanly:

• Office-specific markup. Paragraphs carry class="MsoNormal", styles are full of mso- properties only Office reads, empty <o:p> tags pad the text, and conditional comments wrap list bullets and pictures.
• Images in a side folder. Pictures go to a folder beside the file (guide_files/). Send the .htm alone and every image breaks; send both and the reader has a folder to unpack.
• Formatting where structure should be. A line typed in bold 16 pt instead of styled as Heading 2 exports as a styled paragraph, so outlines, screen readers and skimmers lose the hierarchy.

"Web Page, Filtered" strips some Office extras but keeps the image folder and most class names. Either way you have a file, not a link: you can't see whether anyone read it, and every revision is another attachment.

<!-- A bold line, exported by Save as Web Page -->
<p class=MsoNormal><b><span style='font-size:16.0pt'>First week</span></b><o:p></o:p></p>

<!-- The same line, styled as Heading 2 and converted cleanly -->
<h2 id="first-week">First week</h2>

Three ways to convert Word to HTML that hold up

A converter. Dedicated docx to HTML converters, command-line or web-based, read the styles inside the file and write semantic tags. The output is usually an unstyled fragment: the structure is right, and the design is yours to add with CSS.

An AI prompt. Attach the .docx, or paste its text, into Claude, ChatGPT or Gemini and ask for one HTML document under explicit rules (the next section has them). If the assistant is connected to HTMLvault through the MCP server, it can publish the result in the same conversation with create_link.

Document publishing. Skip the HTML step: send the .docx to HTMLvault's REST API, and it builds a themed, self-contained page with light and dark modes and returns a tracked link.

The first two leave you with HTML you own. HTMLvault serves a published page as written and adds no stylesheet or fonts of its own, so the look is entirely yours. The third trades that control for speed: no CSS to write, no image folder to manage.

Conversion rules for turning a Word document into a web page

Hold any converter's output to these rules, and paste them into the prompt when an AI tool does the work. Each one can be followed literally.

1. Heading styles become headings. Heading 1, 2 and 3 map to h1, h2 and h3, in order, with no skipped levels. Bold, large text is a paragraph; apply the heading style in Word before converting.
2. Paragraphs and lists keep their type. Body text becomes p. Bulleted and numbered lists become ul and ol with one li per item, never paragraphs that begin with a typed bullet.
3. Real tables stay tables. A Word table becomes a table, with th for header cells and td for the rest. Don't flatten a table into text, and don't build one out of columns lined up with tabs.
4. Close every element. Write each </p>, </li>, </td>, </tr> and </tbody> explicitly. HTMLvault refuses malformed HTML rather than repairing it, and omitted end tags can push a long document past its limit of 1,000 nested levels.
5. Images travel with the page. In HTML you publish yourself, point each img at an https URL, or redraw charts as inline SVG. An <img src="data:…"> does not survive, because HTMLvault removes data: URLs from src. A data: URI inside CSS is kept, but base64 swells the file toward the 5 MB limit and costs an AI tool output tokens.
6. The page carries its own CSS, and none of Office's. Put styles in one style block and load any web font yourself; a bare fragment renders in browser defaults. Strip every mso- property, MsoNormal class, o: tag and conditional comment.
7. Every section gets an id. An id on each section and table gives you, or an AI agent, a stable anchor for changing one part later without replacing the page or its URL.

As a prompt, the rules fit in a few lines:

Convert the attached Word document into one HTML document.
- Heading 1/2/3 become h1/h2/h3. Never skip a level.
- Paragraphs become p; lists become ul or ol with li.
- Every Word table stays a table; header cells are th.
- Close every element, including p, li, td, tr and tbody.
- No mso- styles, MsoNormal classes, o: tags or comments.
- Images use the https URLs I list; never a data: URL in src.
- Give each h2 section and each table a unique id.
- Put all CSS in one style block in the head.

Publishing a .docx with HTMLvault document publishing

Document publishing is a REST API endpoint: POST /api/v1/links/document. Send it a Word .docx, or an HTML fragment with figures (SVG, Mermaid, Vega-Lite or PNG), and HTMLvault builds a themed, self-contained page with light and dark modes. The page gets the same checks as every publish: personal data and secrets against your account's scanning policy, outside URLs against Google's unsafe-URL lists. When the source changes, the page can be republished from it.

It suits anyone whose source of truth is a Word file (operations leads, consultants, whoever owns the policy guide) and any script that produces report fragments and shouldn't need a stylesheet for each one. The fragment option is the middle path: let a converter or an AI tool write the structure, and let HTMLvault supply the theme.

To use it, create an API key (see API Keys: Generate, Use, and Revoke) and call the endpoint from a script, a Zapier step or any tool that can make an HTTP request. The REST API guide covers authentication and the other link endpoints. An assistant working through the MCP server publishes HTML it writes itself, which is the prompt route above.

Worked example: a 24-page onboarding guide, published and tracked

An operations team keeps its onboarding guide in Word: policies, a first-month schedule, an equipment checklist, an office floor plan. Every new hire gets it, and it changes every quarter.

1. Prepare the file. Section titles use Heading 1 to 3, the schedule and checklist are Word tables rather than tab-aligned text, and the floor plan is an inserted picture. Accept or reject every tracked change, delete the comments and save, so the file you send is the approved version.
2. Send it. A short script posts the .docx to /api/v1/links/document with the team's API key.
3. Read the response. The first call is refused and returns findings instead of a URL: the laptop-setup section still held a live API key for a test system. Replace it with a placeholder in Word and send again; the second call returns a link. The scanner is regex-based and costs no AI tokens, and depending on the account's policy a staff phone list can be flagged the same way. How to scan HTML for API keys covers what it looks for.
4. Check the page. Open it on a phone and a laptop, in light and dark mode. Confirm the headings form the outline you expect, both tables kept their columns and the floor plan appears.
5. Share it. Create one tracked link per new hire, on your branded subdomain or custom domain if you have one. Add a password if the guide holds internal detail, and an expiry that covers the onboarding period: on Free, links expire after 30 days; Pro lets you set anything from an hour to never.
6. See who read it. Per-link analytics show views, repeat visits, scroll depth and time on page for each hire's link. Scroll depth that stops at 40% means that hire never reached the expense policy near the end, which calls for a short reminder rather than a second attachment.
7. Update it next quarter. Edit the .docx, republish from the revised file, and the links the new hires already hold show the current guide.

What to clear first, and the limits

• Review history is yours to clear. Tracked changes, comments and hidden text belong to editing, not to the page. Resolve them in Word before sending, whichever route you use, instead of leaving a conversion step to decide which revision counts.
• Page furniture has nowhere to go. A web page scrolls and has no pages, so headers, footers, page numbers, page breaks and text boxes pinned to a page position have no natural home. Move anything a reader needs into the body.
• Expect a themed page. Document publishing builds the page in HTMLvault's theme, with light and dark modes. If it must match your own stylesheet exactly, convert with a tool or a prompt and publish the HTML as a normal link, which is served as written.
• Size. A stored page is at most 5 MB. For HTML you generate yourself that is too long to produce in one response, append mode sends it in chunks of up to 200 KB and publishes on the final call.

If Word is where you write, keep writing there. Style the headings, build real tables, clear the review marks and send the file. The reader gets a page that works properly on a phone, and you find out who opened the guide and how far they got, which no attachment ever told you.