Remark vs Showdown
Remark vs Showdown: an AST-based Markdown processor with a plugin ecosystem against a single-file regex converter. One is infrastructure; the other is a script you outgrow.
The short answer
Remark over Showdown for most cases. Remark parses Markdown into a real syntax tree (mdast) you can inspect, transform, and lint with a deep plugin ecosystem.
- Pick Remark if need real Markdown processing — plugins, custom syntax, MDX, linting, sanitization, or any transform that requires understanding document structure rather than guessing at it
- Pick Showdown if want a zero-config, single-file converter to dump Markdown into HTML in a legacy browser bundle and you will never touch the output pipeline again
- Also consider: If you only render trusted Markdown and care about raw speed and bundle size, markdown-it beats both — it's faster than Showdown and lighter than the full Remark/unified stack.
— Nice Pick, opinionated tool recommendations
Architecture: AST vs string-mangling
This is the whole fight. Remark parses Markdown into mdast — a real Abstract Syntax Tree — via the unified ecosystem. Every node is addressable: you can walk it, rewrite it, validate it, and serialize it back to Markdown or hand it to rehype for HTML. Showdown is a regex-and-replace converter. It scans strings and substitutes patterns. That works until two features collide — a link inside emphasis inside a list inside a blockquote — and the regex order starts producing surprises you debug by trial and error. Remark's tree means edge cases are nodes, not landmines. Showdown's approach means every new requirement is another regex you bolt onto a stack you don't fully control. One model scales to MDX, syntax extensions, and linting. The other scales to 'please stop breaking when I nest things.' The architecture isn't a detail here; it's the verdict.
Ecosystem and extensibility
Remark inherits unified's plugin culture: remark-gfm for tables and strikethrough, remark-rehype to cross into HTML, rehype-sanitize for XSS-safe output, remark-lint for style enforcement, plus hundreds more, all composing through a single processor pipeline. Need custom syntax? Write a plugin that operates on the tree. Showdown has 'extensions' — lang and output filters that are, predictably, more regex hooks plus some HTML post-processing. They exist, but you're patching a string pass, not transforming structured data, so two extensions that both touch tables will fight. Remark's plugins compose because they all speak mdast. Showdown's compose by luck and ordering. If your Markdown needs are static and tiny, the ecosystem gap is irrelevant. The moment you need GFM correctness, sanitization, or anything bespoke, Remark hands you battle-tested parts and Showdown hands you a TODO.
Bundle size, speed, and the cost of correctness
Showdown's pitch is that it's one self-contained file with no dependencies — drop it in, call makeHtml, done. That's genuinely convenient for a quick browser-side render or a legacy environment without a build step. Remark, being unified plus a parser plus whatever plugins you pull, is a heavier, modular install that expects a real toolchain. So Showdown wins on raw setup friction and a small footprint. But 'small' buys you a parser that's less CommonMark-correct and slower than the modern competition under load. If lightweight is the actual goal, markdown-it is faster than Showdown AND more spec-compliant, which is why Showdown's one advantage is mostly nostalgia. You pay Remark's size for a correct, inspectable, extensible pipeline. You pay Showdown's smallness with correctness debt you eventually refactor away.
Maintenance and where each one ends up
Be honest about trajectory. Showdown projects start fast and quietly accrete a junk drawer of custom regex extensions, sanitization you hand-rolled because there's no rehype-sanitize, and a test file full of 'don't nest this or it breaks' comments. It is maintained, but the architecture caps how far it goes. Remark projects start slower — you assemble a pipeline, learn unified's vocabulary, wire plugins — and then keep going: MDX, linting in CI, Markdown-to-Markdown formatting, multi-format output, all on the same tree. The unified stack powers serious tooling (Gatsby, Prettier-adjacent workflows, docs platforms) for a reason. Pick Showdown and you'll likely migrate off it the day requirements get interesting. Pick Remark and you grow into it. Choosing the tool you'll abandon to save a day of setup is a bad trade, and you know it.
Quick Comparison
| Factor | Remark | Showdown |
|---|---|---|
| Parsing model | mdast AST — structured, walkable, transformable | Regex string substitution |
| Plugin ecosystem | unified ecosystem, hundreds of composable plugins | Regex/output filter extensions, limited |
| Setup friction / bundle | Modular install, needs a real toolchain | Single self-contained file, drop-in |
| CommonMark/GFM correctness | Strong via remark-gfm, spec-aligned | Looser, breaks on deep nesting |
| Scales to MDX/linting/sanitization | Yes — same tree, rehype + remark-lint | No — caps out, hand-rolled patches |
The Verdict
Use Remark if: You need real Markdown processing — plugins, custom syntax, MDX, linting, sanitization, or any transform that requires understanding document structure rather than guessing at it.
Use Showdown if: You want a zero-config, single-file converter to dump Markdown into HTML in a legacy browser bundle and you will never touch the output pipeline again.
Consider: If you only render trusted Markdown and care about raw speed and bundle size, markdown-it beats both — it's faster than Showdown and lighter than the full Remark/unified stack.
Remark vs Showdown: FAQ
Is Remark or Showdown better?
Remark is the Nice Pick. Remark parses Markdown into a real syntax tree (mdast) you can inspect, transform, and lint with a deep plugin ecosystem. Showdown string-matches its way through your content and prays. For anything beyond "turn this readme into HTML once," Remark is the only defensible choice.
When should you use Remark?
You need real Markdown processing — plugins, custom syntax, MDX, linting, sanitization, or any transform that requires understanding document structure rather than guessing at it.
When should you use Showdown?
You want a zero-config, single-file converter to dump Markdown into HTML in a legacy browser bundle and you will never touch the output pipeline again.
What's the main difference between Remark and Showdown?
Remark vs Showdown: an AST-based Markdown processor with a plugin ecosystem against a single-file regex converter. One is infrastructure; the other is a script you outgrow.
How do Remark and Showdown compare on parsing model?
Remark: mdast AST — structured, walkable, transformable. Showdown: Regex string substitution. Remark wins here.
Are there alternatives to consider beyond Remark and Showdown?
If you only render trusted Markdown and care about raw speed and bundle size, markdown-it beats both — it's faster than Showdown and lighter than the full Remark/unified stack.
Remark parses Markdown into a real syntax tree (mdast) you can inspect, transform, and lint with a deep plugin ecosystem. Showdown string-matches its way through your content and prays. For anything beyond "turn this readme into HTML once," Remark is the only defensible choice.
Related Comparisons
Disagree? nice@nicepick.dev