Real .docx out of real HTML — headings, tables, lists, links — and back again, all in your browser
| HTML | Becomes in the .docx | Status |
|---|---|---|
<h1>–<h6> | Word heading styles (Heading1–6) — navigation pane and TOC ready | Native |
<strong> / <b> | Bold runs | Native |
<em> / <i> | Italic runs | Native |
<a href> | Clickable hyperlinks | Native |
<ul> / <ol> / <li> | Real numbered/bulleted lists (Word numbering, not typed bullets) | Native |
<table>, <th>, <td> | Native OOXML tables — sortable and restylable in Word | Native |
<p>, orphaned inline text | Paragraphs (loose text is auto-grouped into them) | Native |
External CSS files, <script>, <iframe> | Dropped — a .docx is a flow document, not a browser | Not carried |
| Page layout (columns, nav bars, backgrounds) | Collapsed to the document flow | Not carried |
Every "Native" row was confirmed by converting the sample above and unzipping the result: document.xml carries pStyle Heading1, <w:tbl>, numPr numbering, hyperlink references, and bold/italic run properties. Want the page exactly as it renders instead? Print-to-PDF is the right tool for that; this converter trades pixel fidelity for a document you can edit.
A .docx file is a zip of XML parts — paragraphs, runs, styles, numbering definitions. The converter walks your HTML's DOM, maps each element to its OOXML counterpart, and packs the result with the docx library, all inside this tab. The same walk in reverse turns a .docx back into HTML with inline styles for sizes, weights, and alignment.
The sample preloaded above — a heading, a paragraph with bold, italic, and a link, a two-item list, and a 3-row table — converts to a .docx of about 7 KB whose main part, document.xml, is exactly 4,865 bytes holding 10 paragraphs. Unzip that file and you find Heading1 applied to the title, a real <w:tbl> for the table, numPr list numbering for the regions, and a hyperlink relationship for the link. Run the result through the Word → HTML tab and you get 936 characters of HTML back, with the h1, the table, and both list items intact. Round trip, structure intact — that's the whole promise of the tool, demonstrated by the tool.
Paste the HTML into the converter and click Convert: the tool parses your markup on the spot and builds a real .docx — headings land as Word heading styles, tables as native OOXML tables, lists with real numbering, and links as clickable hyperlinks. Download the file and open it in Word, Google Docs, or LibreOffice. Everything happens in your browser, so confidential content never touches a server. Pasting into Word directly works too, but it flattens structure: headings arrive as bold text, not heading styles, which breaks navigation panes and generated tables of contents.
The semantic core: h1-h6 headings become Word heading styles, p becomes paragraphs, strong/b becomes bold runs, em/i italic, a href stays a clickable link, ul/ol/li get real list numbering, and tables become native Word tables. Inline sizing like font-size carries over where Word has an equivalent. What does not carry: external CSS files, JavaScript, iframes, and page layout — a .docx is a flow document, not a pixel-perfect render of the page.
Yes — the tool's second tab runs the opposite direction. Open a .docx and it returns clean HTML with headings, tables, lists, links, and basic inline styling (12pt font sizes, bold, italics) as HTML tags. That's the direction you want for migrating Word content into a CMS, a rich-text editor, or an email template, and it's the same engine, so what one direction builds the other can read.
No. The conversion engine — docshift, wrapping the docx OOXML library — runs as JavaScript inside this page. Your HTML or .docx is read into memory, converted, and handed back as a download; no file or fragment ever leaves your machine. After the page loads you can go offline and it still works.
Because a Word file is a flowing document, not a web render. Multi-column layouts collapse to one column, navigation bars become a stack of links, background images vanish, and fonts fall back to Word's defaults unless the HTML spells them out inline. Structure survives; presentation mostly doesn't. If you need the page exactly as displayed, print-to-PDF from the browser is the honest tool for that job.
Yes. Tables arrive as real Word tables you can sort and restyle — verified on the sample in this page: a three-row HTML table becomes a native OOXML table, and a two-item list arrives with Word's own numbering. Deeply nested structures (a list inside a list inside a table cell) convert level by level; spot-check complex documents, and keep the HTML simple — plain paragraphs and semantic tags convert the cleanest.