Plate 43
Marked vs markdown-it: 14 KB vs 42 KB Gzip, Same Speed
Aditya Challa5 min read
I bundled both Markdown parsers on this box: marked 18.1.0 came in at 14,051 B gzip against markdown-it 15.0.2 at 41,591 B, about 3× smaller. Rendering the same 282 real ShopperCove posts (1.75 MB of Markdown), both ran at about 11.5 MB/s, so speed did not decide anything.
Short answer: pick marked when bundle size matters and you already sanitize the HTML yourself. Pick markdown-it when you render text you do not control, because its defaults escaped raw HTML and refused a javascript: link that marked passed straight through. No affiliate links in this post.
What I tested
- Machine: 8 vCPU Intel Xeon / 15 GB RAM shared Linux cloud box, tested 6 Oct 2026 about 01:13–01:14 IST.
- Versions: marked 18.1.0, markdown-it 15.0.2, Node 22.20.0, esbuild 0.28.2 (browser and neutral ESM, minify, then gzip -9).
- Fixture: /workspace/bench-marked-markdown-it/. Size entries import each parser and render one short string. Speed: render all 282 body-clean-cms.md files from my drafts folder, 15 rounds, median, after 5 warm-up passes. I ran it twice and flipped the order the second time.
- Findings: gzip 14,051 B vs 41,591 B. Run 1 (marked first): 151.6 vs 150.5 ms for the full corpus. Run 2 (markdown-it first): 147.1 vs 153.0 ms. On disk, marked was about 0.5 MB; markdown-it was about 2 MB plus about 1 MB across its 6 dependencies.
- Safety check: input with a script tag and an img onerror. marked kept both as live HTML. markdown-it escaped both to text. A x link became a real href in marked; markdown-it left it as plain text.
- One surprise: only 22 of 282 posts rendered identically, even after I normalized whitespace and quote entities. The gap was defaults, not bugs. marked turns bare URLs into links and renders - [ ] task lists; markdown-it needs linkify: true for the first and a plugin for the second.
- Not tested: plugins (markdown-it-anchor, marked-highlight), syntax highlighting, streaming, CommonMark spec conformance, Deno/Bun, server-side caching, or DOMPurify cost on top of marked.
How big is each parser in a browser bundle?
| Build (esbuild minify) | Minified | gzip -9 |
|---|---|---|
| marked 18.1.0 | 46,497 B | 14,051 B |
| markdown-it 15.0.2 | 100,073 B | 41,591 B |
The browser and neutral builds came out byte-identical for both. If you ship a client-side preview, that 27 KB gzip gap is real; I track budgets like this with size-limit vs bundlesize, and source-map-explorer vs webpack-bundle-analyzer shows where the bytes go.
Is marked faster than markdown-it?
| Run (282 posts, 1.75 MB, median of 15) | marked | markdown-it |
|---|---|---|
| run 1, marked first | 151.6 ms (11.6 MB/s) | 150.5 ms (11.6 MB/s) |
| run 2, markdown-it first | 147.1 ms (11.9 MB/s) | 153.0 ms (11.4 MB/s) |
Not in a way you would notice. The two runs swapped the lead and stayed within 4%. At about 0.5 ms per average post, the parser is unlikely to be your build bottleneck; a formatter pass costs more, as my oxfmt vs Prettier Markdown test found.
Which one is safer with user content?
| Input | marked defaults | markdown-it defaults |
|---|---|---|
| script tag in text | kept as HTML | escaped to text |
| img with onerror | kept as HTML | escaped to text |
| javascript: link | rendered as href | not linked |
| bare https URL | auto-linked | plain text unless linkify: true |
| - [ ] task item | checkbox | plain text without a plugin |
marked's own README warns that it does not sanitize output and points to DOMPurify. If you go with marked for comments, previews, or CMS fields, budget for that extra library. markdown-it calls itself safe by default, and my test matched that for these two cases.
Which one should you pick?
| Situation | My pick |
|---|---|
| Static site build from your own Markdown | either; marked is simpler |
| Client-side preview where every KB counts | marked, plus a sanitizer for untrusted text |
| Comments or user-submitted Markdown | markdown-it |
| You need a plugin ecosystem (anchors, footnotes, containers) | markdown-it |
| GFM task lists and autolinks with zero config | marked |
Bottom line: marked 18.1.0 shipped about 14 KB gzip against markdown-it at about 42 KB, and both rendered my 282-post corpus at the same speed. Who should not switch: a team that renders untrusted input with markdown-it today. Moving to marked means adding and maintaining sanitization, which eats most of the size win. For the rest of the frontend toolchain, see Biome vs ESLint + Prettier and knip vs depcheck to prune the parser you drop.
How this was made: I installed marked and markdown-it on the ShopperCove box, measured esbuild minify+gzip sizes, rendered 282 of my own draft posts in two order-flipped runs, ran an HTML and link safety check, and saved the JSON results. The write-up was drafted with AI help and checked against that output.
Sources
- https://github.com/markedjs/marked
- https://marked.js.org/
- https://www.npmjs.com/package/marked
- https://github.com/markdown-it/markdown-it
- https://www.npmjs.com/package/markdown-it
Related
- https://www.shoppercove.com/blog/size-limit-vs-bundlesize
- https://www.shoppercove.com/blog/source-map-explorer-vs-webpack-bundle-analyzer
- https://www.shoppercove.com/blog/oxfmt-0-72-native-markdown-formatter-prettier-parity-october-2026
- https://www.shoppercove.com/blog/biome-vs-eslint-prettier
- https://www.shoppercove.com/blog/knip-vs-depcheck
- https://www.shoppercove.com/blog/dprint-vs-prettier
- https://www.shoppercove.com/blog/svgo-vs-svgr
- https://www.shoppercove.com/blog/vite-vs-parcel
Lab evidence
What I found running this
Hands-on on ShopperCove box 6 Oct 2026 ~01:13-01:14 IST (8 vCPU Intel Xeon / 15 GB shared Linux, Node 22.20.0). marked 18.1.0 vs markdown-it 15.0.2 (default options), esbuild 0.28.2 browser+neutral ESM minify + gzip -9. Fixture /workspace/bench-marked-markdown-it/. Size: 14,051 vs 41,591 B gzip (46,497 vs 100,073 B min). Speed: all 282 body-clean-cms.md drafts (1,751,838 B), 5 warm passes, 15 rounds median; run1 marked first 151.580 vs 150.533 ms; run2 markdown-it first 147.070 vs 153.001 ms. Safety: marked kept <script> and img onerror as HTML and rendered javascript: href; markdown-it escaped both and did not link. Parity: 22/282 identical after whitespace + quote-entity normalization; diffs from GFM autolinks and task lists (markdown-it needs linkify:true / plugin). Disk ~0.5 MB vs ~2 MB + ~1 MB in 6 deps. Raw: res-bundle.json, res-speed-run1.json, res-speed-run2.json, res-safety.json, res-parity.json. Not tested: plugins, highlighting, streaming, CommonMark conformance, Deno/Bun, DOMPurify cost. No affiliate.