Beauty Diagram
Diagram type

Mermaid Mindmap Syntax & Examples

Reference for Mermaid mindmap syntax — root nodes, indentation-based hierarchy, node shapes, icons, and markdown labels. Copy-paste examples for workshops & brainstorming.

Use this page to connect a high-intent search query to the right problem-solution narrative.

At a glance

A syntax reference for Mermaid's `mindmap` grammar — read this when you need to know how indentation maps to hierarchy, how to pick a root shape, or how to add icons, then try the result in the editor.

What is a Mermaid mindmapRoot node — declaration and shapeHierarchy via indentationNode shapes — beyond the defaultIcons & markdown labelsCommon patterns & gotchas
Rendered proof
Mindmap for a product kickoff.
Theme · Slate
Open this diagram in editor
Beauty Diagram launch Beauty Diagram launch Positioning Mermaid-first Presentation-readyoutput Users Engineers Designers Product managers Channels Docs mentions Dev communities Integrationpartners
View Mermaid sourcePlain-text diagram syntax — copy or edit directly.
diagram.mmd
1mindmap
2  root((Beauty Diagram launch))
3    Positioning
4      Mermaid-first
5      Presentation-ready output
6    Users
7      Engineers
8      Designers
9      Product managers
10    Channels
11      Docs mentions
12      Dev communities
13      Integration partners

What is a Mermaid mindmap

A Mermaid mindmap is a radial tree diagram with a strong central node and branches that fan outward in increasing levels of detail. The mindmap diagram type was introduced as experimental in Mermaid v9.4 and is still officially marked experimental in current releases — but the basic grammar has been stable for over a year and is safe to use in production documentation. Mindmaps are right when the structure is hierarchical and non-sequential: workshop brainstorms, product feature breakdowns, taxonomy explorations, kickoff agendas. If the content has an inherent order, use a flowchart or timeline instead.

Root node — declaration and shape

Every mindmap starts with the `mindmap` keyword followed by the root node declaration. The root sits at the centre of the rendered diagram, so its shape carries visual weight. `root((Label))` renders as a circle (the most common choice). `root[Label]` renders as a rectangle. `root(Label)` renders as a rounded rectangle. `root))Label((` renders as a cloud. `root)Label(` renders as a hexagon. Choose by visual emphasis — a circle reads as the primary subject, a cloud reads as a more loose / brainstormy theme.

  • `root((Label))` — circle (default, strongest emphasis)
  • `root[Label]` — rectangle (formal subject)
  • `root))Label((` — cloud (workshop / brainstorm tone)
  • `root)Label(` — hexagon (decision / pivot point)

Hierarchy via indentation

Mindmap structure is encoded entirely through indentation — there are no curly braces, dashes, or bullets. A line indented further than the previous line is a child of that previous line. A line at the same indentation level is a sibling. Each indentation level renders one more ring outward from the root. Mermaid is lenient about how much you indent (two or four spaces both work) but the indentation must be consistent within a diagram. Inconsistent indentation is the single most common reason a mindmap doesn't render the structure you expected.

Node shapes — beyond the default

Each non-root node can take the same shape modifiers as the root. `Branch[Rectangle]`, `Branch(Round)`, `Branch((Circle))`, `Branch))Cloud((`, `Branch)Hexagon(`, `Branch{{Squiggly}}` are all valid. Plain text without brackets renders as a default rounded node. Use shapes deliberately — varied shapes signal different categories (decisions vs facts vs questions). Most clean mindmaps stick to one or two shapes and reserve the unusual ones (cloud, hexagon) for emphasis.

  • `Plain text` — default rounded node
  • `Label[Square]` — rectangle (formal sub-topic)
  • `Label((Circle))` — circle (key concept)
  • `Label{{Squiggly}}` — bang shape (callout)

Icons & markdown labels

Mindmap nodes can carry icons and markdown formatting. Icons use the `::icon(name)` syntax appended after the node: `Marketing ::icon(fa fa-bullhorn)` adds a Font Awesome bullhorn icon to the Marketing node. Markdown labels use the backtick form: ``Title `with **bold** text` ``. Both features are useful when the mindmap will be presented (workshop summary, planning overview) rather than just sketched. Avoid overusing icons — one or two per branch reads as deliberate; one per node reads as cluttered.

Common patterns & gotchas

Three patterns cover most real mindmaps. Topic breakdowns use a strong-root + balanced branches structure — workshop summaries usually look like this. Decision trees use a root with each branch leading to a separate outcome (use sparingly; flowchart is usually better for actual decisions). Stakeholder maps put the project at the root with branches per stakeholder group and sub-branches per concern. The most common gotcha: mixing tabs and spaces in indentation breaks the parser silently. Stick to spaces consistently. Second gotcha: very deeply nested branches (5+ levels) become unreadable — split into multiple mindmaps if depth grows past 4.

  • Mixed tabs/spaces in indentation breaks parsing — pick one and stick to it
  • More than 4 levels deep reads as cluttered — split into multiple mindmaps
  • Indentation must be consistent within a single diagram
FAQ

Mermaid Mindmap Syntax & Examples — frequently asked questions

When is a Mermaid mindmap the right choice?

Mindmaps fit hierarchical, non-sequential content: workshop brainstorms, product feature breakdowns, stakeholder maps, taxonomy explorations, agenda overviews. Pick a flowchart instead when the content has an inherent order (process diagrams), pick a timeline when chronology is the point, and pick a Gantt when parallel work streams matter. Mindmaps are about breadth-and-depth structure, not flow.

How does the indentation work in Mermaid mindmap syntax?

Indentation is the structure — there are no curly braces, dashes, or bullets. A line indented further than the previous line is its child; a line at the same indentation is a sibling. Two or four spaces both work, but the indentation must be consistent within a single diagram. Mixing tabs and spaces breaks parsing silently, so pick one and stick to it. The deeper a node is indented, the further out it renders from the root.

How do I pick a shape for a mindmap node?

Use shape modifiers: `Label[Square]` for rectangle, `Label(Round)` for rounded, `Label((Circle))` for circle, `Label))Cloud((` for cloud, `Label)Hexagon(` for hexagon, `Label{{Bang}}` for the bang/squiggly callout shape. The same modifiers work on the root and any branch. Pick deliberately — varied shapes signal different categories (decisions vs facts vs callouts). Most clean mindmaps use one or two shapes and reserve the unusual ones for emphasis.

Can I add icons to mindmap branches?

Yes. Append `::icon(name)` after a node label — for example `Marketing ::icon(fa fa-bullhorn)` adds a Font Awesome bullhorn icon. Both Font Awesome and a small built-in icon set are supported. Use icons sparingly — one or two per branch reads as deliberate emphasis, but one per node makes the diagram feel cluttered. For workshop-output mindmaps that will be presented, a few icons on the top-level branches usually hits the right balance.

Why does my mindmap render with the wrong structure?

Almost always indentation. Either tabs and spaces got mixed (the parser is silent about this and just produces an unexpected tree), or the indent depth is inconsistent (some siblings are at 2-space depth and others at 4-space depth, which Mermaid interprets as different levels). Open the source in a code editor with whitespace markers visible and confirm every level uses the same indentation depth. If structure is still wrong after that, the second most common cause is that a label contains a colon or other character that the parser is treating as a special token.