Upload a .docx and your Markdown is written into that file's layout: its heading, body, quote, code and table styles, its paper size and margins, its headers and footers, its list numbering and its theme fonts. The template's own body text, cover page and embedded fonts are not carried over.
Project Charter
This charter authorises the Atlas migration and names its sponsor.
| Role | Name | Date |
|---|---|---|
| Sponsor | J. Okafor | 2026-09-12 |
| Lead | M. Reyes | 2026-09-12 |
Upload your department's .docx above and these headings take its styles.
This preview is HTML. It shows the structure the .docx will have, not your template's Word styling — a browser cannot render a Word style sheet. The styles appear when you open the downloaded file.
Headings, lists, tables and code as usual. The content does not need to know anything about the template.
Any Word file works: a past report, a letterhead, a thesis template. Its styles, page setup, headers, footers, numbering and theme are read in your browser, and the file is never uploaded.
Your text, their document. Headings, quotes, code and tables take the fonts and spacing your template defines, on its paper, inside its margins, headers and footers.
A .docx is a zip archive. Alongside the text in word/document.xml it carries word/styles.xml, which defines what Heading 1, Normal, Quote and every other named style look like; word/numbering.xml, which defines list bullets and numbering schemes; word/settings.xml; word/theme/theme1.xml, which is where fonts written as "+Headings" or "+Body" are actually resolved; the header and footer parts, with their own images and links; and, inside the document, a section-properties block that fixes paper size, orientation and margins.
MDtoDOCX reads those parts and merges them into the file it has just built. Your Markdown is written out first as paragraphs that reference styles by name — a # becomes a paragraph styled Heading 1, a fenced block becomes Source Code, a pipe table uses Table Grid, a blockquote uses Quote — and then the layout parts from your .docx are written over the packed archive. Because the paragraphs only reference styles, they inherit whatever your template says those styles should look like, and because the surrounding parts come from your file too, they land on your paper inside your headers. This is the mechanism behind Pandoc's --reference-doc flag, which is why a reference document prepared for Pandoc works here without changes.
Style definitions first: the paragraph styles Normal, Title, Subtitle, Heading 1 through Heading 6, Quote, List Paragraph, Caption and Source Code; character styles such as Hyperlink and Verbatim Char; and table styles, including Table Grid or a custom one your organisation uses. For each of those the font, size, weight, colour, alignment, indentation, line spacing, space before and after, borders and shading come from your file.
Then the parts around them. The document theme is copied whole, which is what makes a style recorded as "+Headings" or "Calibri Light (Headings)" resolve against your typefaces rather than ours. The body section properties are copied: paper size and orientation, all four margins together with the header, footer and gutter distances, page borders, page-number format, columns, vertical alignment, a distinct first page, text direction and the document grid. Every header and footer that section refers to — default, first-page, odd and even — is copied as its own part, and so is everything inside it, so a letterhead image and a page-number field arrive intact and any external link still points where it did. Finally numbering.xml is merged rather than replaced, with ids offset so your bullet and numbering schemes sit alongside ours, and a whitelist of settings.xml — hyphenation, default tab stop, mirrored margins, different odd and even headers, compatibility flags and the theme language — is layered on top.
Five things stay behind. The template's own body text and cover page are never copied: every paragraph in the output comes from your Markdown, there is no switch to keep the template's content, and Pandoc's --reference-doc makes the same choice. Fonts embedded in the file are not copied either, so a template that leans on a licensed typeface packed into the .docx will fall back to whatever the reader has installed — install the font or name one they already have. Document metadata in docProps, meaning company, category and any custom properties, stays ours rather than yours. Watermarks and background shapes live in the template's body, so they leave with it, and so do content controls and building blocks. Footnote and endnote separators, printer settings and the attached-template pointer are excluded deliberately, because they refer to parts and ids that belong to your package and not to the output.
They fill the gaps, and a precedence setting decides how large the gaps are. Both of its modes agree on the important half: anything your template genuinely defines wins — named styles, page setup, headers and footers, numbering, theme and the whitelisted settings. They differ only where the template says nothing. The default, fill-gaps, keeps our document defaults and our definitions for the styles a normal Word file never mentions, so Code, CodeLabel and Quote keep our font and size. Template-wins stands the converter's typography down entirely: your document defaults replace ours, and our remaining fallback styles stop pinning a font and size so they inherit your theme fonts instead. Paper size and margins are identical either way, because a reference document always carries section properties and those always win.
Editing a .docx at the package level is the kind of thing that produces a "the file is corrupt" dialog, so the merge is checked before you get it. Content types and relationships are rebuilt on save instead of being patched, and no part enters the archive without a registered content type. The finished package is then validated: every part must have a content type, every internal relationship must point at a part that exists, relationship ids must be unique, and the XML must parse. If any of that fails, the conversion returns the unmerged document with a warning rather than a file Word would refuse to open.
Open Word, create a blank document, and change the built-in styles through the Styles pane rather than formatting text directly: right-click Heading 1, choose Modify, set the font by name, then the size, colour and spacing. Repeat for Normal, the other heading levels, Quote and your table style. Then set the page up as you want the finished document to look — paper, margins, and the header and footer with your logo and page numbers — because those now travel with the file. Save the empty document and upload that. Editing the style is the part that matters. Selecting a heading and pressing the bold button applies direct formatting, which lives on that one paragraph and travels nowhere; changing the style definition writes the intent into styles.xml, where every document that uses the style picks it up and where this converter can read it. It is also why a document formatted by hand makes a poor template even though it looks right on screen.
We do not offer a template gallery. Your organisation already has documents that look correct; reusing one is faster and more accurate than picking from a list of strangers' designs.
Uploading a template is a Pro feature, so the free converter cannot load one. The preview on this page is HTML, and a browser cannot render a Word style sheet, so it shows the structure your document will have rather than your template's typography; the styling becomes visible when you open the downloaded .docx. If you only need a consistent font rather than a full house style, the free converter's font and paper options may already be enough. Tables in your Markdown follow the template's table style and keep every property described on the tables page, and the same template applies to LaTeX equations and Mermaid diagrams in the same document. If you work from the command line, the Pandoc tutorial explains the reference-doc flag and how the same file behaves in both. Plans and the refund window are on the pricing page; if the output is not what this page describes, tell us at support.
| Template behaviour | MDtoDOCX | Pandoc --reference-doc | Paste into your template |
|---|---|---|---|
| Heading and body style definitions | From your .docx | From your .docx | Only if you reapply each heading by hand |
| Table and code style definitions | From your .docx | From your .docx | Pasted tables keep the formatting they came with |
| Page size, orientation, margins | From your .docx, in both precedence modes | From your .docx | From the document you paste into |
| Headers, footers, logos | From your .docx, images and links included | From your .docx | From the document you paste into |
| List numbering definitions | Merged in from your .docx | From your .docx | Pasted lists override them |
| Theme fonts and colours | From your .docx, so "+Headings" resolves | From your .docx | From the document you paste into |
| Template body text and cover page | Not carried — your Markdown is the whole body | Not carried | Kept, you type into the document |
| Preview before download | HTML preview of structure, not Word styling | No | n/a |
| Install required | None | Pandoc | None |
| Template file leaves your machine | No, merged in your browser | No | No |
| Reuse a Pandoc reference doc | Yes — styles and page setup both apply | Yes | n/a |
word/styles.xml, the theme, the section properties, the header and footer parts, numbering.xml and part of settings.xml — are merged into the output there, and the finished file is zipped up locally as well. Nothing about the template is transmitted.odttf part, and those parts are not copied, so the style still names the font but a reader who does not have it installed sees a substitute. Install the font, or point the style at one your readers already have.--reference-doc behaves the same way. Every paragraph in the output comes from your Markdown, so the template's cover page and its existing body do not appear, and there is no option to keep them or to append to them. Anything anchored in that body leaves with it, including watermarks, background shapes, content controls and building blocks. Headers and footers are the exception, because they are separate parts, and those are copied.