Mermaid Complete Guide: Flowchart / Sequence / Gantt / ER / Class β 7 Diagrams, Drop into GitHub
The worst part of drawing flowcharts isn't drawing β it's changing them. Lucidchart drag-and-drop, Excalidraw rebuilds β every requirement change starts over. **Mermaid describes diagrams in plain text**: version control, git diff, multi-person collaboration β all solved. This guide uses our `mermaid-editor` tool as the worked example, covering syntax for the 7 diagram types, 3 gotchas I've hit, and how it integrates with GitHub / Notion / Confluence.
Why Mermaid replaced half my Lucidchart / draw.io use cases
Plain text vs drag-and-drop differs in the cost of one edit:
- Drag-and-drop: open file β find the box β double-click β edit text β save β re-export PNG β replace the image link in README
- Mermaid: open markdown β change one character β commit
Plus version control wins: git diff shows exactly how the diagram changed β diagram logic gets reviewed at the PR stage. Architecture docs in PNG are "frozen decisions"; in Mermaid they're "living docs."
Mermaid is NOT for: detailed visual design (posters, slide hero visuals), advanced UML (activity diagrams with swim lanes), org charts beyond ~30 nodes.
Which of the 7 diagram types to pick
flowchart: most common. Decision trees, API call flows, processes. flowchart LR is horizontal, TD is top-down.
sequenceDiagram: multi-service interaction. React β API gateway β DB β cache β for microservice chains, sequence is 100x clearer than flowchart.
gantt: project timeline. Set dateFormat YYYY-MM-DD, group via section, express dependencies with after task1. Show your boss directly β no need for Project / Notion timelines.
classDiagram: OOP design. For SDK / framework design with inheritance / interfaces.
erDiagram: database relationships. The standard format for talking to DBAs about schema.
mindmap: brainstorming, article outlines.
pie: percentage visuals. Simple but effective for retros.
GitHub / Notion / Confluence / Obsidian all just work
GitHub (Issues, PRs, Wiki, README): write a `mermaid code block β GitHub's render engine handles it. Write architecture PRs with the flowchart and code in the same commit β reviewers see everything in one view.
Notion: same mermaid code block (post-2024).
Confluence: use the "Mermaid Macro" or install the Atlas Plugin.
Obsidian: native support β great for technical notes.
Your own site: render with mermaid.js client-side, or generate SVG at build time with mermaid-cli. This tool is the client-side live-render reference implementation.
3 gotchas I've hit
1. CJK node names can break parsing
A[Start server] --> B[Check connection] usually works, but mixed CJK + special chars (γ, /, () sometimes confuses the parser. Hit a weird syntax error? Wrap CJK in quotes: A["Start server"].
2. Gantt date formats vary by renderer
Default is dateFormat MM-DD but GitHub may only accept YYYY-MM-DD. When writing project timelines, always declare full year-month-day for cross-platform safety.
3. Browsers crash on huge flowcharts
Flowcharts with > 100 nodes take ~2 seconds to render and create huge DOM β mobile browsers may OOM. Fix: split into smaller diagrams (< 30 nodes each), link them via sub-pages.
Advanced: documentation as code
Write Architecture Decision Records (ADRs) in Mermaid under /docs/adr/, reviewed alongside code.
Approach:
1. Each ADR is a .md file
2. Lead with a 2β3 sentence decision summary
3. Use Mermaid for the architecture diagram in the middle
4. End with "why this choice" + "alternatives considered"
Why it works: 6 months later a new hire onboards, reads git log + the ADRs, and understands why the system is shaped this way. Beats Confluence "decision wikis" because code and docs change together β no drift.
Reference: adr-tools (github.com/npryce/adr-tools), Architectural Decision Records spec.
Writing architecture docs / issue descriptions / project timelines? Live-preview in [the Mermaid Editor](/en/tools/mermaid-editor) β rendering is fully client-side, nothing leaves your machine β then drop the ```mermaid block straight into GitHub.