Markdown to Word & PDF Converter

Paste your Markdown into the box on this page, or drop a .md file onto it, then press Download .docx. The file that comes back is a normal Word document you can open in Microsoft Word, Google Docs, LibreOffice or Pages and keep editing — there is no signup, no watermark and no page limit. If you want the same document as a PDF, press the second button; both files are built from the same reading of your Markdown, so they match each other.

Yes, and that is the part most converters get wrong. Your # and ## headings become Word’s built-in Heading 1 and Heading 2 styles, which is what makes the navigation pane work and what lets you insert a table of contents that updates itself. Numbered lists get real Word numbering definitions rather than digits typed into the text, so adding an item renumbers the rest. Tables are real Word tables with a header row that repeats when the table crosses a page break, and links are clickable hyperlink relationships, not blue text.

Both buttons are on the same page and use the same input, so you can download the .docx and the .pdf one after the other without re-uploading anything. They come from one parse of your document, which is why the numbering, the table columns and the heading levels agree between the two files. The PDF is drawn as real text, not as an image of text, so it can be searched, selected, copied and read by anything that extracts PDF text.

Because of an indentation rule. GitHub, CommonMark and almost every editor indent a nested list item by two spaces, but several older Markdown libraries require four and treat a two-space indent as a sibling rather than a child. The result is a converted document where a three-level outline has silently collapsed into one flat list — it looks fine at a glance, which is what makes it dangerous. This converter uses a CommonMark-compliant parser, so two-space nesting produces the hierarchy you wrote, down to as many levels as you use.

Your Markdown is sent to the converter, rendered in memory and returned in the same response. It is never written to disk, never logged and never retained after the request finishes, and there is no account to attach it to. That said, this is a public tool on the open internet: if a document is covered by an NDA or contains secrets, convert it somewhere you control instead.

Headings 1 to 6, bold, italic, inline code, strikethrough, links, hard line breaks, blockquotes (including nested ones), bullet and numbered lists at any depth, ordered lists that start at a number other than one, GitHub task lists, fenced and indented code blocks with a language label, tables with per-column alignment, horizontal rules, definition lists, footnotes and YAML front matter — which is recognised as metadata and used for the title rather than printed as a stray paragraph. Images are the one deliberate gap: a remote image is described in place with its alt text and URL rather than downloaded, because fetching arbitrary URLs on a visitor’s behalf is a security hole this tool will not open.

That is the most common use for this tool, and README files are exactly where converters usually fail: they are full of two-space nested lists, fenced code blocks inside numbered install steps, badge images and tables. All of those are handled here. Drop the README.md straight in, and if the file starts with a # title, that title is used as the document title and the filename instead of being duplicated as a second heading.

Yes — drop the file on the editor and it comes back as Markdown rather than being rejected. It is the same engine running backwards, so a .docx round-trips well: headings, tables with their column alignment, numbered lists, links, code blocks and blockquotes all survive, and converting the result back to Word returns them. A PDF is a much weaker source, because a PDF stores positioned glyphs rather than a document — there is no record that a line was a heading. Structure is reconstructed conservatively from line joining, blank lines, bullet characters and numbered section prefixes, so prose and lists come through well and tables do not.

HTML as one self-contained, responsive page with the stylesheet inlined and nothing loaded from the network. EPUB as a real e-book, split into chapters at each H1 with a working table of contents. ODT for LibreOffice, RTF for anything older, plain text reflowed and wrapped at 78 columns with headings underlined, CSV containing every table in the document, and Markdown itself — which normalises a messy document rather than changing its format. All nine come out of the same parse, so they agree with each other about heading levels, list numbering and table columns.

Yes, and this is worth being specific about because it is where converted documents usually break. Column widths are measured from the real font metrics of the content: every column is guaranteed at least the width of its widest unbreakable word, and whatever space is left is shared in proportion to how much more each column wants. Without that, a narrow unit column next to a column of sentences ends up with less room than its own header needs, and the renderer splits the word down the middle — the stacked, seemingly-overlapping columns you have probably seen in a converted PDF. When even the minimum widths do not fit, the padding and the type size step down together, and a table that still cannot be made readable in portrait is given a landscape page of its own.

Yes. The output is a standard Office Open XML .docx using built-in styles and standard numbering definitions rather than anything Word-specific, which is what non-Microsoft editors read most reliably. Fonts are the one place to expect small differences: the document asks for Calibri for body text and Consolas for code, and an editor that does not have them will substitute something close.