.md or .markdown file, preview it locally in your browser, then export it to Word (.docx) or PDF in one click. Your file is never uploaded to a server.or click this area to pick a .md / .markdown file
Markdown is good for writing, not necessarily for handing over. Once the document is written, what the other side wants is usually a .docx: something they can comment on, turn track changes on in, or pour into the organisation's template — or simply because the process only accepts Word. Status reports, requirement docs, tender material and coursework all fall into this category. The point of converting is not to swap the extension, it is to turn plain-text markup into styles Word understands: headings become outline levels a table of contents can be built from, lists become real numbered lists, and tables become table objects whose column widths you can drag.
If the text will keep changing, or someone needs to comment on it or run it through a review cycle, convert to Word. If it is final and about to be sent out, printed or archived, convert to PDF: the layout holds up across machines, lines don't reflow because the recipient is missing a font, and it is harder to alter casually. A common working pattern is to export Word for the review round, then export a PDF at the end as the frozen copy. This page produces both — convert the same Markdown twice.
Pandoc is the standard answer for this kind of conversion: templates, reference styles, cross-references and bibliographies are all under your control, which makes it the right choice for maintaining a documentation pipeline over time. The price is installing it, setting up a LaTeX environment and remembering the flags. If you just have this one file to hand over, that setup is a poor trade — this page converts inside the browser, with no install and no sign-up, and the file never leaves your computer. When you actually need long-term automation, Pandoc will still be there.
Raw HTML written straight into the Markdown, deeply nested tables and custom CSS have no equivalent structure in Word or PDF, so they get simplified during conversion. Extended syntax that depends on a particular renderer — maths formulas, Mermaid diagrams — will not come out looking the way it does on the original platform. Images referenced from local disk paths cannot be fetched either, because the browser cannot read other files in the same folder; switch those to image URLs. Take a look at the preview before converting: what you see there is close to what you will export.
This tool previews .md and .markdown files in the browser and exports them as Word (.docx) or PDF. Word suits documents you intend to keep editing, review or send to someone else for changes; PDF suits a final version meant for printing or for keeping the layout fixed.
Common Markdown constructs are mapped onto the matching document structures wherever possible: headings, paragraphs, bold, italic, lists, links, blockquotes, tables and code blocks. Because Word supports only a limited subset of HTML/CSS, unusually complex layouts, nested tables or custom styles may need a little tidying up after export.
The PDF is generated from the preview shown on the page, which suits ordinary documents, manuals, notes and technical write-ups. For the best result, use a clear heading hierarchy in your Markdown, avoid very wide tables, and try not to put overly long code or links on a single line.
No. Reading the file, parsing the Markdown, previewing it and exporting to Word or PDF all happen locally in your browser, and the page never uploads your document. That makes it fine for internal documents, meeting minutes, study notes and unpublished technical articles.
A Markdown file normally stores only the path to an image, not the image itself, and for security reasons the browser cannot read other local files sitting in the same folder. Link to images by URL, or insert local images by hand once the Word file has been exported.
The common GitHub Flavored Markdown constructs are supported — tables, task lists, line breaks and code blocks. Platforms differ slightly in which extensions they implement, so advanced syntax such as footnotes, math formulas or Mermaid diagrams may not export the way it renders on the platform you wrote it for.
The browser preview, the Word document and the PDF are each produced by a different rendering engine, so fonts, page breaks, table widths and code-block wrapping can vary. Check the preview on the page first, then download the format you need; for anything official, do the final layout pass in Word or a PDF editor.
It suits READMEs, technical notes, project and API documentation, course notes, meeting minutes, blog drafts and simple reports. For documents packed with complex diagrams, formulas or custom components, use a dedicated documentation build tool for the final typesetting.