curiositech/mermaid-graph-renderer

Mermaid Graph Renderer

Renders Mermaid diagrams to production-quality SVG, PNG, and PDF in web and offline contexts. Covers the full spectrum from lazy-loaded client-side rendering to 1000x-faster native Rust batch export.

Core Constraint

Mermaid.js requires browser APIs (document.createElement, SVGTextElement.getBBox()) to compute text dimensions. Every non-browser rendering path must either embed a headless browser or reimplement the renderer from scratch. This constraint shapes every decision below.

---

When to Use

✅ Use for:

• Rendering Mermaid diagrams on web pages (performance-optimized)
• Exporting diagrams to SVG, PNG, or PDF (offline/CLI)
• Setting up CI/CD pipelines that generate diagram images
• Choosing between rendering libraries for a project
• Optimizing Mermaid load time on documentation sites

❌ NOT for:

• Writing Mermaid syntax (use mermaid-graph-writer)
• Rendering non-Mermaid formats (PlantUML, GraphViz — see Kroki)
• General image processing or manipulation

---

Rendering Decision Tree

flowchart TD
  A{Where are you rendering?} -->|Browser| B{Performance matters?}
  A -->|CLI / CI| C{Volume?}
  A -->|Server-side| D{Must avoid client JS?}

  B -->|Yes| E[Lazy-load mermaid.js]
  B -->|No| F[CDN script tag]

  C -->|1-10 diagrams| G[mermaid-cli]
  C -->|10-100 diagrams| H{Need multiple formats?}
  C -->|100+ diagrams| I[mmdr Rust renderer]

  H -->|Mermaid only| G
  H -->|Multiple languages| J[Kroki]

  D -->|Yes, zero JS| K[Build-time with Puppeteer]
  D -->|Some JS OK| E
  K -->|Slow builds warning| L[rehype-mermaid + Playwright]

---

Web Rendering

Option 1: Lazy-Loaded mermaid.js (Recommended)

Best for documentation sites, blogs, and apps where only some pages have diagrams.

How it works: Check for .mermaid elements before loading the library. The ~480 KB cost is only paid on pages that actually need it.

// Lazy load pattern — only loads mermaid.js when diagrams exist
function initMermaid() {
  const diagrams = document.querySelectorAll('.mermaid');
  if (diagrams.length === 0) return;

  const script = document.createElement('script');
  script.src = 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.min.js';
  script.onload = () => {
    mermaid.initialize({ startOnLoad: false, theme: 'neutral' });
    mermaid.run({ nodes: diagrams });
  };
  document.head.appendChild(script);
}

// Handle initial load + SPA navigation
document.addEventListener('DOMContentLoaded', initMermaid);
// For SPA route changes: call initMermaid() after navigation

Key detail: Handle both initial page load AND client-side navigation (SPA route changes) by re-running mermaid.run() when new diagram content appears.

| Aspect | Value | |--------|-------| | Bundle size | ~480 KB (core + lazy diagram chunks) | | Render time | ~50-200 ms per diagram (client) | | Diagram coverage | Full (all Mermaid types) | | Best for | Docs sites, blogs, apps with occasional diagrams |

Option 2: @mermaid-js/tiny

Pre-bundled subset for CDN use. All diagram types included upfront (no lazy-loading of diagram chunks). Smaller total but loaded eagerly.

Use when: You know exactly which 1-2 diagram types you need and want a single-file import.

Option 3: Build-Time SSR (Usually Not Worth It)

Render SVGs at build time using Puppeteer/Playwright. Sounds appealing; painful in practice.

Costs:

• Adds ~280 MB to node_modules (Puppeteer + Chromium)
• ~2-3 seconds per diagram to spin up and render
• A 5-second build becomes 45 seconds for ~30 diagrams
• Docker/CI headaches (Chrome needs to be installed)

When actually worth it: Strict zero-JS requirements, or sites with hundreds of diagrams where you want to eliminate client-side rendering entirely.

Tools: rehype-mermaid (uses Playwright), rehype-mermaid-cli (wraps official CLI).

Verdict: Unless you have strict zero-JS requirements, lazy-loaded client-side rendering is the better trade-off.

---

Offline / CLI Rendering

Option 1: mermaid-cli (Official)

The canonical CLI tool. Launches headless Chromium, renders, captures output.

# Install
npm install -g @mermaid-js/mermaid-cli

# Basic usage
mmdc -i input.mmd -o output.svg
mmdc -i input.mmd -o output.png -b transparent
mmdc -i input.mmd -o output.pdf

# With config
mmdc -i input.mmd -o output.svg -t dark --configFile mermaid.config.json

# Batch: process Markdown with embedded diagrams
mmdc -i document.md -o document-with-images.md

# Docker
docker run --rm -v $(pwd):/data minlag/mermaid-cli -i /data/input.mmd -o /data/output.svg

| Aspect | Value | |--------|-------| | Speed | ~3000 ms per diagram (Chromium overhead) | | Output | SVG, PNG, PDF | | Size | ~280 MB (Puppeteer + Chromium) | | Coverage | Full (all Mermaid types, 100% parity) | | Best for | 1-50 diagrams, when accuracy matters most |

SVG gotcha: Output SVGs contain <foreignObject> elements that break in Inkscape and rsvg-convert. Fix: set "htmlLabels": false in config, or export to PNG instead.

Option 2: Kroki (Multi-Format Gateway)

Unified HTTP API that routes diagram source to appropriate rendering engine. Supports 25+ languages (Mermaid, PlantUML, GraphViz, D2, Excalidraw, etc.).

# Render via HTTP (self-hosted or kroki.io)
curl -X POST https://kroki.io/mermaid/svg \
  -H 'Content-Type: text/plain' \
  -d 'flowchart LR
    A --> B --> C' \
  -o diagram.svg

# Self-host via Docker Compose
# docker-compose.yml needs: yuzutech/kroki + yuzutech/kroki-mermaid

| Aspect | Value | |--------|-------| | Speed | ~500-2000 ms (network + render) | | Output | SVG, PNG, PDF, JPEG | | Languages | 25+ (Mermaid, PlantUML, GraphViz, D2, etc.) | | Best for | Multi-language pipelines, CI/CD, documentation generators |

When Kroki wins: You need multiple diagram languages in one pipeline. When it doesn't: Simple "render one Mermaid diagram" — overkill.

Option 3: mmdr (Native Rust — Fastest)

Native Rust reimplementation. No browser, no Node.js. ~1000x faster than mermaid-cli.

# Install (Rust toolchain required)
cargo install mmdr

# Usage
mmdr input.mmd -o output.svg
mmdr input.mmd -o output.png  # via resvg, no browser

| Aspect | Value | |--------|-------| | Speed | ~3 ms per diagram (1000x faster) | | Output | SVG (native), PNG (via resvg) | | Size | ~5-10 MB binary | | Coverage | 13 diagram types (partial parity) | | Best for | Batch processing 100+ diagrams, CI/CD speed |

Trade-off: Not all Mermaid features are supported yet. Flowcharts and sequence diagrams are mature; other types vary. Accept imperfection for speed, or fall back to mermaid-cli for edge cases.

No <foreignObject> issue: Uses native SVG text, so output works with Inkscape and other SVG tools.

---

Comparison Matrix

| Criterion | mermaid.js CDN | mermaid-cli | Kroki | mmdr (Rust) | |-----------|---------------|-------------|-------|-------------| | Runtime | Browser | Node + Puppeteer | Docker | Native binary | | Speed/diagram | ~100 ms | ~3000 ms | ~1000 ms | ~3 ms | | SVG quality | Excellent | Excellent | Excellent | Good (improving) | | PNG quality | N/A | Good | Good | Good (resvg) | | PDF export | N/A | Yes | Yes | Not yet | | Install size | ~480 KB | ~280 MB | ~1 GB (Docker) | ~5-10 MB | | Diagram coverage | Full | Full | Full | 13 types | | CI/CD fit | Poor | Moderate | Good | Excellent | | Multi-language | No | No | Yes (25+) | No |

---

Recommendations by Use Case

| Use Case | Recommendation | Why | |----------|---------------|-----| | Docs site with occasional diagrams | Lazy-loaded mermaid.js | Only loads on pages that need it | | Next.js / SSR app | Dynamic import, ssr: false | Don't fight build-time rendering | | CI/CD generating static docs (Mermaid only) | mmdr for speed, mermaid-cli for accuracy | 1000x faster vs. 100% feature parity | | CI/CD with multiple diagram languages | Kroki | One API for PlantUML + Mermaid + GraphViz | | Batch export for print/PDF (100+ diagrams) | mmdr + mermaid-cli fallback | Fast for most, accurate for edge cases | | Desktop apps (Electron/Obsidian/VS Code) | Built-in mermaid.js | Chromium already embedded |

---

Anti-Patterns

SSR Obsession

Wrong: Spending 3 days setting up Puppeteer in CI to avoid 480 KB of client JS. Right: Lazy-load mermaid.js. The 480 KB is only fetched on pages with diagrams. Most users won't notice.

foreignObject Surprise

Wrong: Exporting SVGs from mermaid-cli and wondering why Inkscape can't open them. Right: Set "htmlLabels": false in config, or export to PNG directly.

One Tool for Everything

Wrong: Using mermaid-cli for 500 diagrams in CI (25 minutes of build time). Right: Use mmdr for batch, mermaid-cli for the few diagrams that need full parity.

Output Contract

This skill produces:

• Rendered diagram output (SVG or PNG) from Mermaid syntax
• Rendering configuration with theme, dimensions, and export settings
• Diagram validation with syntax checking and error reporting
• Batch rendering pipeline for multiple diagrams with consistent styling