Word to HTML — paste from Word or Google Docs, get clean markup

Word does not put plain HTML on the clipboard. It puts an entire Office document there: a stylesheet thousands of lines long, conditional comments addressed to old versions of Internet Explorer, namespaced tags like o:p and w:sdt, a class such as MsoNormal on every paragraph, mso- properties inside every style attribute, and a span wrapped around almost every word. Most editors accept all of it, which is why a pasted paragraph refuses to match the rest of the page and why the HTML behind it is unreadable.

Script tags, style blocks, on* event handlers, javascript: URLs, mso- style properties, MsoNormal and every other Mso class, o:p and w: and v: namespaced tags, conditional comments including the StartFragment markers, font tags, and spans that carry nothing but Word styling. Inline style attributes go too, so the text inherits your own site’s typography instead of arriving in 11pt Calibri.

Structure. Headings stay headings, including Word heading styles that arrive as a class rather than an h1 tag. Bulleted and numbered lists are rebuilt as real ul and ol elements with correct nesting — Word does not send lists as lists, it sends flat paragraphs with the bullet typed in as a character, so this has to be reconstructed rather than passed through. Tables keep their rows, cells and merged spans. Bold, italic, underline, strikethrough, superscript, subscript and hyperlinks all come through.

A .docx file is a ZIP archive of XML, so reading one in the browser means shipping an unzipper and a schema parser, and the result still would not match what you see on screen. The clipboard already carries HTML that Word generated itself from the document you are looking at. Using it is both more accurate and far lighter.

No. The cleaning runs inside this page using the browser’s own HTML parser. Nothing you paste is sent over a network and nothing is saved — not to a server and not to your browser’s storage. That matters here more than on most tools, because the documents people clean this way are usually client work, contracts and internal reports.

Yes. Google Docs has its own habits: it never emits a b tag, it writes span style="font-weight:700" instead, and it wraps the whole selection in a b tag whose own style says font-weight:normal. Both are handled — the weight becomes a strong tag, and the wrapper is unwrapped rather than treated as bold. Outlook, Apple Pages, LibreOffice and web pages all go through the same cleaner.

Because a Word image is almost never usable. Word writes src="file:///C:/Users/…", which is a path on the machine the document was written on, and Google Docs writes a googleusercontent URL that refuses to load from another site. Turning images on keeps the tags for the cases where they do point somewhere public, but it will not magically host your pictures. Upload those separately.

No, and the tool is built so that it cannot. The clipboard HTML is parsed with DOMParser, which produces a document with no browsing context: scripts do not execute and images are not fetched. The cleaner then works from an allow-list — only listed tags and only listed attributes on those tags survive, so event handlers and unknown attributes are dropped without the code ever naming them. Finally, the preview is built as React elements from that cleaned tree rather than injected as an HTML string, so there is no path where pasted markup becomes markup of this page.

Pasting through a plain text editor gives you the clipboard’s plain-text flavour, which keeps Word’s bullet characters, its non-breaking spaces and its line-wrapping. This tab works from the cleaned document instead, so bullet glyphs are gone, non-breaking spaces become ordinary spaces, paragraphs are separated by a blank line, and table rows come out tab-separated so they paste back into a spreadsheet as columns.

Those live in inline style attributes, and the point of this tool is to remove them. Text that carries Calibri 11pt and a hard-coded colour will clash with every site it lands on, and it is the single most common reason a pasted article looks wrong. Semantic tags describe what the content is; your own stylesheet decides how it looks.

No fixed one. The cleaner handles a long report without trouble because it is a single pass over a parsed document. Very large pastes are limited by what your browser will put on the clipboard, not by this page.