Mammoth.js vs Pandoc WASM: which converts Word to Markdown better?
Converting Word to Markdown in the browser is a solved problem — twice. Mammoth.js has shipped for years as a lean JavaScript library that turns docx into clean semantic HTML, while Pandoc, the heavyweight document converter, now compiles to WebAssembly and runs the same engine desktop users rely on. They take genuinely different engineering routes, and the difference shows up precisely where your documents get complicated.
This comparison looks at how each pipeline works, then walks through the dimensions that decide conversion quality in practice: tables, footnotes, math, images, lists and tracked changes. Both tools run entirely client-side, so this is not a story about privacy — it is a story about fidelity versus footprint.
Two pipelines, two philosophies
Mammoth reads the OOXML inside a docx file and walks it with one goal: semantic content, not appearance. Paragraph styles it recognises become HTML elements, and everything it deems decorative — most colours, fonts, spacing, text boxes, shapes — is discarded. The result is famously clean HTML that needs little post-processing before it enters a CMS.
Pandoc takes the same file apart with a native docx reader, but instead of emitting HTML directly it builds a typed abstract syntax tree. Every reader — docx, odt, epub, LaTeX — produces that same tree, and every writer consumes it. The indirection is what lets one parse produce Markdown, HTML, reStructuredText, LaTeX or even a fresh docx.
How mammoth's style map works
Mammoth's extension point is the style map: a list of rules that map Word styles onto HTML elements. A rule can declare that a paragraph carrying a particular style becomes an h1, or that bold runs using a custom character style become strong. Style maps let you adapt mammoth to house templates without touching its code, and they are the main reason teams with a single, well-disciplined source template get excellent results.
The trade-off is that anything outside the map and outside mammoth's supported feature set simply disappears. For memos and blog posts that is a feature — the output stays clean. For dense reports with footnotes and equations, silence is not golden.
Tables, footnotes and math
Tables are the first wall. Mammoth converts simple tables into plain HTML tables, but nested tables are outside its model, and merged cells rarely survive intact. Pandoc parses the full table structure of the file, so every row and cell survives the parse; what happens next depends on the writer, because Markdown pipe tables cannot express merged cells at all — that limit belongs to the format, not the converter — while the HTML writer keeps the whole table with all of its cells.
Footnotes tell a similar story. Mammoth collects notes at the end of the document and links back to them, which is fine for web reading. Pandoc models footnotes as first-class nodes and emits genuine Markdown footnote syntax or native LaTeX footnotes. Equations are the clearest gap: mammoth does not convert Word's OMML math, while pandoc turns it into standard LaTeX notation.
Images, lists and revisions
Images work in both. Mammoth inlines them as data URIs in the browser by default and lets you swap in a custom handler; pandoc extracts the media into a folder alongside your Markdown, or embeds it as base64 when you need a single self-contained file. Everyday bulleted and numbered lists are solid in both engines, including multi-level nesting.
Tracked changes are the subtle one. Pandoc exposes an explicit trackChanges option with accept, reject and all, so you choose which revision state lands in the output. Mammoth has no revision model; the text comes out as if every change had been accepted, with no record of what was accepted. Neither tool replaces Word for legal review — but only one of them gives you a choice.
Bundle size and delivery
The size gap is the honest cost of fidelity. Mammoth's browser bundle weighs a few hundred kilobytes and loads with the page. Pandoc compiled to WebAssembly is roughly 58 megabytes — a real download on first use. Inside a Web Worker, though, the cost is paid once: this site caches the engine in the browser's Cache API, so the Network panel stays empty on every conversion after the first, and the tool keeps working offline.
Caching changes the arithmetic. An engine that downloads exactly once, per browser, and then behaves like a local binary is a very different proposition from re-downloading it every session. For a team converting daily, the one-off cost is trivial against the hours saved re-fixing broken tables.
Output reach and citations
Mammoth outputs HTML and, with a little help, Markdown — nothing else. Pandoc's writer list is the point of the AST: the same parse that yields Markdown can yield reStructuredText for Sphinx docs, LaTeX for a journal submission, or a re-styled docx via a reference template. Citations close the loop: pandoc runs citeproc against a bibliography and a CSL style, resolving cite keys into formatted references inline — mammoth has no equivalent.
Reach extends to input formats too. Pandoc reads odt, epub, HTML, LaTeX, Org and more, so one engine covers a whole content pipeline. Mammoth is a docx specialist by design, and a very good one; just do not ask it to be a hub.
Choosing between them
The two tools are not really competitors; they answer different questions. If your documents are simple, your bundle budget is tight, and HTML or Markdown is the only target, mammoth is excellent — small, fast and predictable, especially paired with a style map tuned to your template.
If your source files carry footnotes, equations, complex tables or citations, or you need more than two output formats, pandoc is the honest pick, and running it as WebAssembly preserves the zero-upload privacy both tools share. This site chose the pandoc route for exactly that reason: fidelity first, with the download paid once and cached. Try your hardest document in both and let the output decide.