Why copying AI answers into Word still breaks (and how I built a client-side converter for LaTeX & tables)

Live Tool:​ https://aitoword.online/en/

If you only work in Markdown, copying responses from ChatGPT, Claude, or DeepSeek is trivial. You click the copy button, paste it into Obsidian, VS Code, or Notion, and everything renders as expected.

The problem starts when you have to hand off a deliverable to someone who lives in Microsoft Word—a client report, a lab assignment, or internal documentation.

Depending on how you copy an AI response into Word, you usually hit one of three failure modes:

1. Highlighting and copying from the browser UI: Word inherits the web page's inline CSS. You get dark or gray background shading behind every paragraph, mismatched font sizes, and broken table widths.
2. Clicking the AI's "Copy" button and pasting into Word: Because the clipboard contains raw Markdown, Word treats # headings, ** bold markers, and | table pipes as literal characters.
3. The LaTeX math wall: ChatGPT and DeepSeek frequently wrap inline and block equations in \(...\) and \[...\] (or $...$ and $$...$$). Pasting these into Word leaves you with raw TeX strings. Worse, many online converters rasterize equations into static PNG images, meaning you cannot fix a single subscript in Word without re-generating the whole document.

To solve this without installing a local Pandoc + LaTeX toolchain on every machine, I built Aitoword—a free, browser-based converter that turns AI Markdown and supported LaTeX into editable .docx files entirely on the client side.

Here is a breakdown of the formatting problems it solves, how the in-browser pipeline works, and the trade-offs involved.

1. Normalizing AI Math Delimiters Without Breaking Code Blocks

Standard Markdown math parsers usually look for $...$ and $$...$$. However, most LLMs default to LaTeX-style \(...\) and \[...\] delimiters unless explicitly prompted otherwise.

A naive regex replacement across the whole document will accidentally corrupt escaped brackets inside fenced code blocks or inline code spans (for example, array indexing or regex literals in JavaScript).

Before building the .docx document tree, the parser has to isolate code blocks and inline code tokens first, and only normalize math delimiters in prose nodes:

function normalizeMathOutsideCode(markdown) {
  // Split by fenced code blocks and inline code spans first
  const segments = markdown.split(/(```
{% endraw %}
[\s\S]*?
{% raw %}

|[^\n]+`)/g);

return segments
.map((segment, index) => {
// Odd indices are code blocks/spans; leave them untouched
if (index % 2 === 1) return segment;

  return segment
    // Convert \[ ... \] display math to $$ ... $$
    .replace(/\\\[([\s\S]*?)\\\]/g, (_, expr) => `$$${expr}$$`)
    // Convert \( ... \) inline math to $ ... $
    .replace(/\\\(([\s\S]*?)\\\)/g, (_, expr) => `$${expr}$`);
})
.join('');

}

Once normalized, supported expressions (fractions, roots, subscripts/superscripts, sums, integrals, and basic matrices) are parsed via KaTeX into MathML and mapped into OMML (Office Math Markup Language)​.
When you open the downloaded .docx in Word, the equations are native Word math objects—you can click directly into a fraction or integral and edit the variables using Word's native equation editor. If an expression uses an unsupported macro, the converter does not silently drop it; it preserves the original LaTeX string in the document and flags a notice in the preview panel. (I wrote a more detailed breakdown on how AI LaTeX equations map to editable Word math here.)

2. Turning Pipe Tables and Headings into Native Word Structures

When you paste a raw Markdown table into Word, you get lines of pipe characters (|). When you copy an HTML table from a chat window, column widths often overflow the page margins.
By compiling the Markdown AST directly to Office Open XML (.docx) in the browser:

Headings (H1–H6) map to native Word heading styles, so they immediately show up in Word's Navigation Pane and can be used to generate an automatic Table of Contents.
Markdown tables become native Word table cells with clean borders and header shading. (See the Markdown tables to Word troubleshooting guide for handling wide tables and long cell text.)
Fenced code blocks are kept in a monospace font with preserved indentation rather than collapsing into a single paragraph.

Comparison of Export Methods

3. Privacy by Architecture: Zero Uploads and No External Image Fetches

Many "free online document converters" work by uploading your text or .md file to a backend server, running a Python or LibreOffice worker, and returning a download link. If you are converting internal work notes, unpublished research, or client drafts, uploading that text to a third-party server is a non-starter.
Aitoword runs the entire conversion pipeline locally inside your browser tab:

No server round-trip:​ Whether you paste text or import a local .md / .txt file, the .docx Blob is packed in memory using JavaScript and downloaded directly via URL.createObjectURL().
No external image requests:​ Markdown pasted from web tools sometimes contains external image links (). Automatically fetching and embedding those images from the browser would leak your IP address to external image hosts and hit CORS errors. Instead, Aitoword deliberately converts external image links into plain text descriptions so no outbound requests are triggered.
Starting layout presets:​ Rather than forcing you to use a bloated web-based rich text editor, the tool provides three clean presets (General Report, Academic / Long-form, and Compact Print) with explicit font, line-spacing, and margin parameters, plus a read-only layout preview. Once downloaded, you do your final tweaks and pagination checks in Word itself.

Try It Out

If you regularly need to move ChatGPT, DeepSeek, or Markdown notes into Word without spending twenty minutes fixing equations and stripping # symbols, you can try it here (no account or signup required):

Guide on fixing hashtags, asterisks, and gray backgrounds:​ How to Copy ChatGPT to Word and Fix Formatting Problems

Feedback on edge-case LaTeX expressions or Markdown structures that trip up the parser is very welcome!