Every Pandoc alternative worth knowing, sorted by why you want one

14 August 2026 · 27 min read

Nobody searches for a Pandoc alternative because Pandoc is bad. (What Pandoc actually is, if that is the question underneath.) They search because they wanted an HTML file and found themselves reading about template variables, or because the PDF flag asked for a TeX distribution, or because there is no terminal on the machine where the document lives. The tool is not the problem. The distance between the tool and the job is.

TL;DR

Pandoc is the right answer whenever anything other than HTML comes out of the pipeline — DOCX, EPUB, LaTeX, a typeset PDF, a bibliography — and nothing else on this page comes close on that. If HTML is the only output, the alternative you want depends on the reason you are looking: a browser converter if you want no install and one finished file, marked or markdown-it if the conversion happens inside code you already run, a hosted API or a GitHub Action if it happens in CI and you do not want a package step in the runner, a static site generator if the answer is a site rather than a document. The honest part is at the bottom: four jobs where every substitute here fails and you should install Pandoc instead.

The friction, named precisely

Converting Markdown to HTML with Pandoc is one line. That is not where the cost is.

The cost is the second line. A bare pandoc -t html returns a fragment — headings and paragraphs with no doctype, no <head>, nothing a browser will treat as a page. --standalone fixes that by wrapping your content in Pandoc's default template, which is deliberately plain, and the moment you want it to look like anything you are into --css for a stylesheet, -V for template variables, or --template with a file written in Pandoc's own template language: $body$, $for(author)$, $if(toc)$. No other tool reads that file. It is now part of your build, and somebody has to maintain it.

Then there is the stylesheet problem. --css leaves you with an HTML file that needs a second file beside it, which is exactly wrong if the plan was to email the page to a colleague. Pandoc can inline assets instead, but the flag that does it was renamed between major releases, so check pandoc --help rather than a forum answer from four years ago.

None of this is difficult. It is a real amount of setup for one page, and the amount does not shrink when the job is small. That asymmetry is the entire reason this article exists.

What Pandoc is unmatched at

Be fair to it first, because the fair account is also the useful one — it tells you when to stop reading.

Pandoc reads a document into an internal representation and writes that representation back out in another format. The indirection is the trick: nobody had to write a Markdown-to-DOCX converter, because every reader can feed every writer. That single design decision is why the format list runs to dozens of entries, and why no smaller tool has ever caught up.

A format matrix. One source file, several outputs, kept in step. HTML for the site, DOCX for the reviewer who redlines in Word, EPUB for the reader on a train. Every alternative below does one output well. Pandoc does the matrix.

Academic writing. Maths, cross-references, numbered figures, and --citeproc with a BibTeX file and a CSL style, so the bibliography formats itself in whatever house style the journal demands. Nothing else in this article has a citation processor at all.

Word output in a house style. --reference-doc takes fonts, heading styles and spacing from an existing .docx and applies them to yours. If a template arrived from a legal or marketing team, that flag is the whole reason to install Pandoc.

Filters. A Lua or JSON filter rewrites the document while it is still a tree — renumber every table, strip a section, rewrite every internal link, promote every heading by one level. Doing the same thing with a regular expression over the finished HTML works right up until it does not.

pandoc -f gfm -t docx notes.md -o notes.docx
pandoc -f gfm -t epub book.md -o book.epub
pandoc -f gfm --citeproc --bibliography=refs.bib paper.md -o paper.pdf

The third line carries a caveat worth knowing before you type it. Markdown to PDF is not one of Pandoc's writers. Pandoc makes a PDF by handing the document to a separate engine, and the default is a TeX engine, so that pipeline usually means installing a TeX distribution too — a much larger install than Pandoc itself, and the most common reason somebody decides Pandoc is more than they wanted. --pdf-engine can point at an HTML- or Typst-based engine instead, which is far smaller and handles maths and page layout differently.

Quick comparison: the cheat sheet

The alternatives, by the reason you are looking

Each section below answers a different sentence. Find yours and skip the rest. If you want the wider field rather than the Pandoc-shaped question, the full converter comparison covers the same tools with different weightings.

Pandoc itself — the baseline you are measuring against

Worth one section of its own, because half the people looking for an alternative are really looking for permission to keep using this.

Price: free, GPL licensed.

Technical details and features

• Written in Haskell, distributed as a single binary for the major platforms
• Its own extended dialect by default, with CommonMark and GFM readers selected by flag
• --standalone for a full document; a separate flag inlines images and CSS
• --citeproc, --bibliography and CSL styles for references
• Lua and JSON filters for rewriting the abstract syntax tree mid-conversion

Who should use it? Anybody whose document has to become something other than a web page, now or within the next few months. The template language is a fair price for the format matrix. It is a poor price for one README.

TransformPipe — no install, and one file that opens anywhere

A browser converter suits a document that is not part of a build at all. You open a page, drop the .md file on it, and download HTML. It is worth knowing which online converters upload your file and which do not before you pick one. Signed out, nothing is uploaded: the file is read, parsed and rendered on your own machine, which you can confirm by watching the network tab do nothing while it works.

Price: free. Signing up adds conversion history, share links and API keys, and costs nothing either.

Technical details and features

• Reads GitHub Flavored Markdown, so tables, task lists, strikethrough and fenced code survive
• What downloads is a whole page: a doctype, a <head>, the CSS inside a <style> block, and not one external request
• Any raw HTML in the source is filtered against a fixed allow-list on the way through
• Saves as .html, .md or plain text; a PDF comes out of the browser's print dialog rather than a TeX engine
• Also converts HTML, Word, CSV/TSV and JSON back to Markdown
• The same converter is reachable four other ways: a REST API, a CLI, a GitHub Action and an MCP server

Who should use it? Anybody whose next step is "send this to a person", and anybody on a machine where installing a binary is somebody else's decision. This is the closest substitute for pandoc --standalone --embed-resources, without the install and without the template.

Dillinger and StackEdit — when you are still writing the thing

Both are browser Markdown editors with export, and both are the right answer to a different question: not "convert this file" but "write this document and get HTML at the end". Dillinger exports HTML and PDF and syncs to Dropbox, Google Drive, OneDrive and GitHub. StackEdit keeps working without a connection once it has loaded, and publishes to several destinations when it has one.

Price: free. Dillinger is MIT licensed; StackEdit is Apache 2.0 licensed.

Technical details and features

• Live preview beside the source, with the usual editor conveniences
• Export to HTML and PDF from the browser, no local install
• Sync and publish targets including Drive, Dropbox, OneDrive and GitHub
• Documents live in browser storage or in the connected account, not on your filesystem by default

Who should use it? People composing now rather than converting later. If the file already exists on disk and you only want HTML out of it, a converter is a shorter path than an editor.

Typora — a desktop application instead of a command

The no-terminal answer for somebody who writes Markdown every day. Typora replaces the syntax with its rendering as you type, keeps the files on your own disk, and exports HTML, PDF and Word from a menu.

Price: $14.99 without tax, a one-time purchase covering up to three devices, with a 15-day free trial (checked on typora.io, 8 September 2026).

Technical details and features

• WYSIWYG editing over plain .md files on the local filesystem
• Export to HTML, PDF, Word and several other formats through the application menu
• Themes are CSS, so export styling is editable without a template language
• Handles tables, footnotes, maths and diagrams as editor features

Who should use it? Anybody who writes Markdown daily and wants an application rather than a command. It covers Pandoc's HTML, PDF and Word outputs for one document at a time, with a mouse, and it covers none of them in a script.

Obsidian — exporting from the notes you already keep

Not a converter, but frequently the reason somebody does not need one: the document is already in a vault of local Markdown files, and the export is a menu item away. PDF export ships with the application. HTML export comes from community plugins, which is a real distinction — the core product does not promise it.

Price: free for all purposes, including commercial use; optional commercial licences are sold annually (checked on obsidian.md, 8 September 2026).

Technical details and features

• Vaults are ordinary directories of .md files, so any other tool can read them too
• [[wiki links]], embeds and callouts are extensions: check what your target parser does with them
• Plugin ecosystem covers export, publishing and site generation
• Nothing leaves the machine unless you enable a sync or publish service

Who should use it? People whose Markdown already lives in a vault. The warning is the syntax: a note full of [[wiki links]] converted by a strict GFM parser produces literal double brackets in the output, because those brackets are not Markdown.

VS Code — the shortest path if the file is already open

The preview pane in VS Code is markdown-it underneath, and export arrives through extensions rather than the editor itself. For a README already open in a tab, that beats installing anything.

Price: free.

Technical details and features

• Built-in preview rendered by markdown-it, with GFM features enabled for the preview
• Export extensions wrap the fragment in a document and inline or link a stylesheet — which one, depends on the extension
• Workspace settings can add a custom preview stylesheet
• Nothing is uploaded; conversion happens in the editor process

Who should use it? Developers who need the file currently in the editor and nothing beyond it. Check what the extension puts around the fragment before you send the result to anybody, because "it looked right in the preview" is not the same claim as "it opens right on somebody else's laptop".

marked and markdown-it — the JavaScript route

If the conversion belongs inside code you already run, a library is smaller than a binary and easier to reason about. marked is small and fast with GFM on by default. markdown-it is CommonMark-compliant, has a structured plugin system, and escapes raw HTML unless you tell it otherwise — which is the safer default of the two.

Price: free, both MIT licensed.

Technical details and features

• marked: GFM by default, custom renderers per node type, a lexer you can call for tokens instead of HTML
• markdown-it: passes the CommonMark suite, html: false by default, rules addable and reorderable
• Neither sanitises for you; the documented answer is a dedicated sanitiser over the output
• Both are the engine inside larger tools, so bug reports and edge cases are well travelled

Who should use it? Any project that already has a Node build. The full JavaScript comparison goes through the differences properly, and converting from a terminal has the wrapper script in full — about fifteen lines, which is the honest measure of what Pandoc's --standalone is worth to you.

remark and rehype — when you need to change the document

The unified ecosystem parses Markdown to an AST, lets you rewrite it, then renders. It is the only alternative here that competes with Pandoc's Lua filters, and it competes well.

Price: free, MIT licensed.

Technical details and features

• Two tree formats — mdast for Markdown, hast for HTML — and a plugin to convert one into the other
• remark-gfm for tables and task lists; remark-frontmatter for the YAML header
• The same trees are used to build linters, formatters and codemods over prose
• Sanitising happens on the tree, before HTML exists, which is stricter than filtering strings

Who should use it? Teams that have to alter the document in transit: rewriting every relative link, pulling headings out for navigation, enforcing a house style. If you were reaching for a Lua filter, this is the substitute.

Python-Markdown, markdown-it-py and mistune — the Python route

The same logic in a different language. Python-Markdown is the mature option with a large extension catalogue and is the engine under MkDocs. markdown-it-py is a port of markdown-it, so it brings CommonMark conformance and the same plugin shape. mistune is the fast one.

Price: free. Python-Markdown is BSD licensed, markdown-it-py is MIT licensed, mistune is BSD licensed.

Technical details and features

• Python-Markdown: official extensions for tables, footnotes, attribute lists and table of contents
• markdown-it-py: a port of the JavaScript parser, used where CommonMark behaviour must match
• mistune: pure Python with a plugin system, no compiled dependency
• All three hand back a string, so the document wrapper is a template in your own code

Who should use it? Python projects, documentation builds and anything already importing from PyPI. Test one document with a table in it first: the three libraries disagree about tables, because tables are an extension in all of them rather than core syntax.

cmark-gfm — the small binary inside a build

GitHub's fork of the CommonMark reference implementation, written in C, with the GFM extensions added. It is quick, it has no runtime to install alongside it, and it hands you a fragment with no styling and no wrapper.

Price: free, open source — cmark is BSD licensed, and GitHub's cmark-gfm fork carries its own notice.

Technical details and features

• CommonMark plus the GFM extensions: tables, task lists, strikethrough, autolinks, footnotes as an option
• A C library as well as a command line binary, so it embeds in other programmes
• Flags control raw HTML handling, which matters for untrusted input
• No templating, no CSS, no asset embedding — by design

Who should use it? Builds that already supply their own layout and only need the body. It is the closest thing to Pandoc's speed and single-binary convenience, with none of its range.

A hosted API, a CLI or a GitHub Action — CI without a package step

The CI case is its own problem. Installing Pandoc in a runner is a step that downloads a binary on every job, and TeX in a runner is worse. The alternatives are a request to an API, a dependency-free CLI, or a workflow step that does the conversion for you.

Price: free tier; an account is required to issue API keys.

Technical details and features

• REST endpoint taking Markdown and returning a complete HTML document
• A CLI with no dependencies, for a runner that has a shell and nothing else
• A GitHub Action for converting on push, on merge or on a release tag
• An MCP server, for the case where the thing doing the converting is a model rather than a person

Who should use it? Anybody rebuilding a page on every commit. Publishing from a workflow walks through the pull request version, where the output is attached to the PR rather than deployed. The privacy trade is real and worth stating plainly: a browser conversion keeps the file local, and an API call does not.

Pandoc in Docker — skipping the install, keeping the matrix

Pandoc without installing usually means one of two things. The first is a web front end running Pandoc on somebody else's server, which is fine for a public README and wrong for a draft contract. The second is the official container image, which keeps your machine clean and keeps every format.

docker run --rm -v "$PWD:/data" pandoc/core -f gfm -t html -s README.md -o README.html

Price: free, GPL licensed.

Who should use it? Teams who want one pinned Pandoc across several machines, and anybody on a locked-down laptop that has Docker but no package manager. It is the honest middle: you skip the install without handing your document to a stranger.

Static site generators — the answer when you wanted a site

Hugo, Eleventy, MkDocs, Docusaurus and Jekyll all turn Markdown into HTML, and not one of them is a converter in the sense this page means. Each is a build system. It wants a directory, a configuration file, a set of templates and a deploy target; in exchange it hands back navigation, search, feeds and cross-links across every page at once.

Price: free. Hugo is Apache 2.0 licensed; Eleventy, Docusaurus and Jekyll are MIT licensed; MkDocs is BSD licensed.

Technical details and features

• Each ships a Markdown engine: Goldmark in Hugo, markdown-it in Eleventy by default, Python-Markdown in MkDocs
• Front matter drives titles, dates, tags and navigation order
• Output is a directory tree of HTML with shared assets, meant to be served
• Deployment is part of the model: a build command and a host

Who should use it? Anybody whose output is a set of pages that reference one another. One file and one recipient is the wrong shape for a generator entirely — that job wants a document, not a website.

GitHub's Markdown API — GFM rendered exactly as GitHub renders it

An HTTP endpoint that takes Markdown and returns HTML. It is the only way to get GitHub's own rendering without screen-scraping a page, and the output is a fragment wrapped in nothing.

Price: free, rate limited.

Who should use it? Anybody who has to match GitHub's rendering precisely, and nobody who needs a finished page. Treat it as a reference implementation you can call, not as an export route.

The jobs that genuinely require Pandoc

This is the section a comparison page usually leaves out, so here it is with the hedging removed. Four jobs should not be attempted with anything above.

Anything with a bibliography. If the document cites sources and the citations have to be formatted to a style, --citeproc with a BibTeX file and a CSL style is the tool. There is no substitute on this page. Doing it by hand means maintaining a reference list that goes stale the first time a co-author reorders a section.

A typeset PDF with real page layout. Widows, orphans, figure placement, page numbers, cross-references that say "see page 14". Browser print-to-PDF gets you a readable document and not a typeset one, because the browser is laying out a web page and then cutting it into pages. If the output has to look composed, Pandoc handing off to a TeX or Typst engine is the route, and the extra install is the price.

DOCX in somebody else's template. When a .docx template arrives with mandated fonts, heading styles and spacing, --reference-doc applies it. No Markdown-to-Word converter that skips this step will produce a file the template's owner accepts, and reformatting by hand in Word is a job you will do again next quarter.

EPUB, LaTeX, reStructuredText, MediaWiki, Org and the rest of the matrix. The moment two of those appear in the same requirement, the argument is over. Chaining single-purpose tools to fake a matrix means every format is one tool's edge cases away from breaking, and the breakages arrive separately.

There is one thing Pandoc deliberately does not do, and it cuts the other way: it does not sanitise. Raw HTML in a Markdown file passes straight through to the output, <script> tags included, because faithful conversion is the job it signed up for. --sandbox restricts filesystem access during conversion, which is a different protection. If the file came from outside — a client, a repository, a form submission — you need a sanitising step of your own, and why that has to happen in more than one place is worth ten minutes before you open the result in a browser.

How to choose

1. Write down every output format this document must produce over its life. If DOCX, EPUB, LaTeX or a typeset PDF appears on that list, install Pandoc and stop comparing; every hour spent on a substitute is an hour spent on a tool you will replace.
2. Decide whether the destination is a person or a server. A person needs one self-contained file that opens with the network off. A server needs a fragment your templates will wrap. Picking the wrong one produces either unstyled text in somebody's inbox or a document with two copies of the page furniture.
3. Count the installs the job can bear. A one-off conversion should not require a package manager; a nightly build should not require a browser tab and a human in it. Both mistakes are common and both are obvious in hindsight.
4. Check where the file goes before you convert it. Browser-side conversion keeps the document on your machine and you can verify that from the network tab. An API, a hosted editor and GitHub's Markdown endpoint all mean the document travels, which is irrelevant for a public README and decisive for a contract.
5. Convert one representative file and open the result somewhere else. Not in the tool's preview — a different browser, a different machine, no connection. That single test catches fragments, missing stylesheets, CDN font links and lost tables at once, and it takes about a minute.

Conclusion

The reason "Pandoc alternative" is such a common search is that Pandoc answers a bigger question than most people are asking, and answering a bigger question always costs more. If the document has to become a Word file, an EPUB or a typeset PDF, install Pandoc and learn its templates — it will outlast every other tool named here. If HTML is the only output, pick by the reason you came: a library where the build already lives, a workflow step where CI already runs, a generator when the answer is a site, and a browser converter when what you want is one finished file with nobody's install standing in the way — which is what TransformPipe's Markdown to HTML conversion does, free, in your own browser, with nothing uploaded when you are signed out.

FAQ

What is the best Pandoc alternative for Markdown to HTML?

There is no single one, because Pandoc covers several jobs at once. For one finished page with no install, a browser converter that produces self-contained HTML; for conversion inside code, marked or markdown-it; for CI, an API or a GitHub Action; for a whole site, a static site generator. Each replaces one part of what Pandoc does, and none replaces the format matrix.

Can I use Pandoc without installing it?

Yes, in two ways with different trade-offs. The official Docker image runs the real Pandoc with nothing installed on the host except Docker, which keeps your document local. A hosted web front end also runs Pandoc, but on somebody else's machine, so the file is uploaded — fine for a public README, wrong for anything confidential.

Is Pandoc overkill for converting one Markdown file to HTML?

Usually, yes. A bare conversion returns a fragment, so you need --standalone, and making that output look like anything means a stylesheet flag, template variables or a template file in Pandoc's own language. For one page that somebody has to read, a converter that hands back a complete self-contained document skips all of it.

Why does my Pandoc HTML have no styling?

Because you did not pass --standalone, or you did and got the default template, which is intentionally plain. Add a stylesheet with --css and you now have two files that must travel together; inline the assets instead if the file has to open on its own. That gap between "converted" and "presentable" is the most common reason people start looking for an alternative.

What replaces Pandoc's Lua filters?

remark and the unified ecosystem, more closely than anything else. Both parse the document into a syntax tree you can rewrite before rendering, which is the same shape of solution — rewrite the tree, not the output string. The difference is that Pandoc's tree spans every format it supports, while remark's covers Markdown and HTML.

Do the alternatives handle tables and task lists?

Only if they implement GitHub Flavored Markdown, because tables and task lists are not in the CommonMark specification. marked, cmark-gfm and GFM-configured markdown-it do; a strict CommonMark parser renders your table as a paragraph full of pipe characters and reports no error at all. Convert one file with a table in it before you commit to any tool on this page.

Is a browser converter safe for a confidential document?

It depends entirely on whether the conversion happens in the browser or on a server, and those look identical from the outside. A browser-side converter reads the file with the File API and never sends it, which you can verify by opening the network tab and watching nothing happen. Anything that shows you a progress bar while a server works has your document.