mmdr renders Mermaid diagrams in Rust without launching a browser

The two to three second browser startup mmdr refuses to pay

The official mermaid-cli starts a headless Chromium for every diagram, and the README puts that startup cost at two to three seconds. That overhead, not layout computation, is what dominates a normal render. mmdr is built around removing it: Mermaid syntax is parsed in Rust and written straight to SVG, with no browser, no Node.js and no Puppeteer in the path. The repository description claims 500 to 1000x faster than mermaid-cli, and the README body puts the range at 100 to 1400x.

The comparison table in the README gives concrete figures on an Intel Core Ultra 7 265V running Linux 6.18.7, against mermaid-cli 11.4.2 driven through Puppeteer and Chromium. A flowchart takes 4.49 ms for mmdr against 1,971 ms for mermaid-cli, a 439x speedup. A sequence diagram goes from 2.71 ms to 704x. Those numbers were produced by the author on one machine, so read them as a shape rather than a promise for your hardware.

The audience is anyone who renders Mermaid in a loop: a documentation pipeline with fifty diagrams in it, a Markdown preview that has to feel instant, a CI job that currently spends a coffee break waiting. A single diagram rendered once by hand still incurs mermaid-cli's browser startup overhead.

Fast text metrics trade real font widths for calibrated guesses

The single largest lever inside mmdr is text measurement. Label width decides node width, node width decides how much layout work happens downstream, and getting real widths means loading a font database. mmdr handles this in two ways.

The default path builds a font cache on first run, after which small and common diagrams reach 536x to 919x against mermaid-cli. The second path is the `--fastText` flag, which the README describes as using calibrated fallback widths for ASCII labels in order to avoid the font database load entirely. With that flag the same small diagrams land between 1,601x and 2,069x.

The trade-off is stated plainly in the flag description. Calibrated widths are an approximation of what the font will actually measure, and they are only defined for ASCII. Chinese, Japanese and Korean labels are outside what that shortcut describes, so a diagram full of them under `--fastText` is outside the case the README documents. The warm-cache path is the safer default when labels are not plain ASCII, at a meaningful cost in the speedup numbers.

One more number is worth keeping in mind: the speedup shrinks as diagrams get large. A 200 node flowchart takes 47.00 ms for mmdr against 2,276 ms, which is 48x rather than 1,600x. Real layout work eventually shows up in the profile.

Install paths and the first render you can check

The README lists six installation routes. Cargo from crates.io is the recommended one, and the binary it installs is called `mmdr`. Homebrew, Scoop for Windows, Arch via the AUR and Nix flakes cover the common platforms.

cargo install mermaid-rs-renderer
brew tap 1jehuang/mmdr && brew install mmdr
scoop bucket add mmdr https://github.com/1jehuang/scoop-mmdr && scoop install mmdr

Once the binary is on your path, the quickest check pipes a diagram straight to stdout. Mermaid syntax on one line is enough to see whether the pipeline works end to end:

echo 'flowchart LR; A-->B-->C' | mmdr -e svg

You should get an SVG document on standard output with no browser window and no browser process appearing in your process list. To write to a file, name the input with `-i` and the output with `-o`. Passing `-i -` makes the read from standard input explicit rather than inferred:

echo 'flowchart LR; A-->B-->C' | mmdr -i - -o out.svg -e svg
mmdr -i diagram.mmd -o output.png -e png

The `-e` flag selects the format. SVG is the native path, and PNG goes through the `png` cargo feature, which pulls in resvg and usvg. Both formats are on by default in the feature list, along with `cli`.

For batch work the input can be Markdown rather than a single diagram file. Pointing `-o` at a directory writes every diagram it finds:

mmdr -i README.md -o ./diagrams/ -e svg

By default the SVG keeps the diagram's natural size, with the root `width` and `height` matching the `viewBox` so there is no letterbox padding. `--width` and `--height` override that when a specific pixel size is needed.

Twenty three diagram types, and which categories are thinner

The README lists 23 supported Mermaid diagram types grouped into four families. Core covers Flowchart, Sequence, Class and State. Data covers ER Diagram, Pie Chart, XY Chart, Quadrant Chart and Sankey. Planning covers Gantt, Timeline, Journey and Kanban. Architecture covers C4, Block, Architecture and Requirement. The remainder are Mindmap, Git Graph, ZenUML, Packet, Radar and Treemap.

That spread is the project's main bet: a Mermaid codebase usually mixes a well supported flowchart with one exotic diagram, and the exotic one is what forces a fallback to mermaid-cli. Coverage here is broad enough that many projects would not need that fallback.

The repository layout backs up where the confidence sits. `examples/flowchart_visual_report.rs` and `examples/port_quality.rs` point at visual comparison tooling for the core types, and `benches/` plus the Criterion feature show that performance work has a home. `package.json` is marked private and named mermaid-rs-renderer-dev-tools, and it carries `@mermaid-js/mermaid-cli` at ^11.12.0 alongside vega tooling, which means the comparison numbers come from a development harness rather than from the shipped Rust code.

The `scene` feature is the odd one out in the feature list. It builds a renderer-neutral vector scene with usvg and no rasterizer and no CLI, which is the shape you want when embedding the renderer in something that already owns its own drawing.

Where mmdr is the wrong tool

The project says so itself, near the top of the README: the library is under active early development, visual output is improving, and it may not yet match mermaid-cli in all cases. Bug reports are welcomed. Any adoption that depends on byte-level visual parity with an existing documentation set is being asked to absorb that gap, and the README does not document a conformance threshold, a regression suite for pixel output, or a rollback path.

`--fastText` narrows that gap further for anyone whose labels are not ASCII. The fallback widths it uses are described as calibrated for ASCII labels, so treat that flag as an opt-in for English-only diagrams.

Crate versions move quickly here. The Cargo.toml sits at version 0.3.1 with edition 2024, and the release history shows v0.3.1 on 2026-07-06 after v0.3.0 on 2026-07-03 and v0.2.2 on 2026-04-23. A project that pins its renderer version should expect to revisit that pin, and the README does not document a compatibility or output stability policy across those versions.

The last push was on 2026-10-04, so the code is moving, but a 0.x line with several recent releases means the interface may still shift.

How this differs from mermaid-cli, and what it costs to keep both

mermaid-cli is a Node.js package that drives mermaid inside a real browser, which is why it can reproduce browser text layout and browser rendering fidelity almost by definition. mmdr re-implements the pipeline in Rust with its own text measurement, so it trades exact parity for a render time measured in single-digit milliseconds. Neither side of that trade is a bug; they optimise for different things.

The other difference is deployment. mermaid-cli needs a Chromium download, a Puppeteer install and a Node runtime on the machine doing the rendering. mmdr needs a Rust toolchain to install from source, or nothing beyond the binary once installed. In a container or a CI image that difference decides which one is practical.

The pragmatic setup for many teams is both: mmdr for the bulk of diagrams in a pipeline, mermaid-cli kept for the types where visual parity still matters. The repository already depends on mermaid-cli at ^11.12.0 for its own comparison work, so that combination is the one the author exercises.

Licensing is straightforward on both counts. mmdr is MIT licensed and declares that in Cargo.toml. That permits use inside proprietary tooling and redistribution of the binary; it says nothing about the graphical output, which you should check separately if your diagrams are governed by the licence of the font you end up using.

Editorial conclusion

Adopt mmdr when you render Mermaid in CI, in a batch loop, or inside a Rust service, and where the diagram is a flowchart, class, state or sequence diagram drawn in ASCII labels. Do not adopt it yet for pixel parity with mermaid-cli, for CJK-heavy labels under --fastText, or as the only renderer in a publishing pipeline where diagrams face human review. Verify first by rendering a handful of your real diagrams and diffing them by eye against the mermaid-cli output, since the project itself states that visual quality may not yet match.

Frequently asked questions

Official sources

1. 1jehuang/mermaid-rs-renderer on GitHub
2. Issues
3. License: MIT
4. README
5. Releases