Mermaid Flowchart Maker
Build flowcharts by dragging shapes on a canvas or by writing Mermaid code, and TryMermaid keeps both in sync. Start from the example below, then export PNG or SVG or share a link.
Updated · Editable on the visual canvas
Flowchart example
Rendering preview…
flowchart TD
A[Order received] --> B{Is it paid?}
B -->|Yes| C[Pack items]
B -->|No| D[Send payment reminder]
D --> B
C --> E([Ship order])What is a flowchart?
A flowchart is a diagram that shows the steps of a process as shapes connected by arrows. Rectangles are steps, diamonds are decisions, and the arrows show the order things happen in. In Mermaid you describe a flowchart as text that starts with the flowchart keyword and a direction.
When to use a flowchart
- Documenting a business or approval process
- Explaining the logic of an algorithm or function
- Mapping user journeys and checkout flows
- Troubleshooting guides and decision trees
How to make a flowchart in Mermaid
- Step 1
Open the editor
Open TryMermaid with the example on this page, or start a new diagram with flowchart TD (top to bottom) or flowchart LR (left to right) on the first line.
- Step 2
Add steps and decisions
Drag rectangles and diamonds onto the canvas and rename them in place, or type nodes such as A[Start] and B{Approved?} in the code panel.
- Step 3
Connect the shapes
Connect two shapes on the canvas, or write A --> B in code. Add a label to a link with A -->|Yes| B.
- Step 4
Export or share
Download the flowchart as PNG or SVG, copy it to your clipboard, or copy a share link that keeps your layout.
Which shape to use for which step
Every shape in a flowchart is a claim about what the step is. A rectangle is an action someone or something performs. A diamond is a decision with two or more ways out. A stadium, the rounded shape, marks where the process starts or ends. A cylinder is data at rest, usually a database or a file. Using them consistently means a reader can follow the diagram without reading every word.
Mermaid picks the shape from the brackets around the label, not from a separate setting. A[Step] is a rectangle, B{Decision?} is a diamond, C([Start]) is a stadium and D[(Database)] is a cylinder. Because the bracket carries the meaning, changing a step into a decision is a one-character edit rather than a redraw.
On the TryMermaid canvas the same rule applies in reverse: drop a diamond on the canvas and the code gains the curly braces automatically, so the two views never disagree about what a shape means.
Choosing a direction: TD, LR, BT and RL
The two letters after the flowchart keyword set the direction: TD draws top to bottom, LR left to right, BT bottom to top and RL right to left. TD and TB mean the same thing.
Direction is not only cosmetic. Top to bottom suits a process with many decisions, because each branch gets its own column and the page grows downwards, where scrolling is natural. Left to right suits a pipeline with few branches, such as a build or a delivery flow, and fits better in a wide README. If a flowchart feels cramped, changing the direction is usually a faster fix than moving nodes.
A subgraph can set its own direction with a direction line inside it, which lets you run the overall diagram top to bottom while a group inside flows left to right.
Labelling decisions so people can follow them
A decision diamond is only useful when the arrows leaving it say what the answer was. Write A -->|Yes| B, and the word Yes sits on the arrow. Without those labels a reader has to guess which branch is which, which is the single most common reason a flowchart is misread.
Phrase the diamond as a question with a definite answer, such as Is it paid? rather than Payment. Then every arrow out of it is one of the possible answers, and a missing branch becomes obvious: if you wrote Yes but never No, the diagram itself shows the gap.
Keep the number of branches small. More than three or four arrows out of one diamond usually means two decisions have been squashed together, and splitting them into two diamonds reads better.
Grouping with subgraphs and styling with classDef
A subgraph draws a labelled box around a set of nodes. Use it for steps owned by one team, one service or one system, so a reader can see where a handover happens. Arrows may cross the boundary freely; the box is a grouping, not a wall.
Styling works the same way as CSS. classDef names a style, class applies it to nodes, and style targets a single node directly. Colour is most useful when it means something consistent, such as green for success and red for a failure path. A diagram where every node is a different colour is harder to read than one with no colour at all.
Both features survive export, so a PNG or SVG carries the grouping and the colours with it, and both are written back to the code when you edit on the canvas.
Where a Mermaid flowchart can be published
A Mermaid flowchart is text, so it belongs in the same place as the thing it describes. GitHub renders Mermaid inside Markdown files, which means a flowchart in a README or a pull request shows as a picture rather than as code. That is the main practical reason to write a flowchart in Mermaid instead of drawing one in a graphics tool: it is reviewed like code, and it changes in the same commit as the behaviour it documents.
For everywhere else, export a PNG or SVG, or use an embed so the diagram stays live on a documentation site and updates when you change it. A share link opens an exact copy of the diagram, layout included, which is often quicker than attaching an image to a message.
More worked examples
A decision flow with a loop
Two decisions in a row, with a loop back. The labels on the arrows carry the answers, so a reader follows the path without a legend.
Rendering preview…
flowchart TD
A[Ticket opened] --> B{Enough detail?}
B -->|No| C[Ask for steps to reproduce]
C --> B
B -->|Yes| D{Can we reproduce it?}
D -->|Yes| E[Fix and close]
D -->|No| F[Close as cannot reproduce]Grouping steps with subgraphs
A subgraph groups steps that belong to one team or system. Arrows can cross the boundary, which is how you show a handover.
Rendering preview…
flowchart LR
Start([Order placed]) --> W
subgraph Warehouse
W[Pick items] --> P[Pack]
end
subgraph Courier
S[Collect] --> D[Deliver]
end
P --> S
D --> Done([Delivered])Colouring outcomes with classDef
classDef defines a style once and class applies it to as many nodes as you like, which keeps colour meaningful rather than decorative.
Rendering preview…
flowchart TD
A[Submit expense] --> B{Under 100?}
B -->|Yes| C[Auto-approve]
B -->|No| D[Manager reviews]
D --> E{Approved?}
E -->|No| F[Rejected]
E -->|Yes| C
classDef good fill:#dcfce7,stroke:#16a34a,color:#14532d
classDef bad fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
class C good
class F badFlowchart syntax cheat sheet
| Element | Syntax | What it does |
|---|---|---|
| Direction | flowchart TD | LR | BT | RL | Top-down, left-right, bottom-top or right-left layout |
| Step | A[Text] | Rectangle |
| Rounded step | A(Text) | Rounded rectangle |
| Decision | A{Text} | Diamond |
| Start or end | A([Text]) | Stadium (pill) shape |
| Database | A[(Text)] | Cylinder |
| Arrow | A --> B | Solid link with an arrowhead |
| Labelled arrow | A -->|Yes| B | Link with text on it |
| Dotted arrow | A -.-> B | Dotted link |
| Group | subgraph Title … end | Box around related nodes |
Common mistakes and how to fix them
Parentheses inside a label break the diagram
Fix: Wrap the label in quotes: A["Show error (inline)"]. The same applies to square brackets, curly braces and the pipe character.
A node called end silently breaks the flowchart
Fix: Rename it or capitalise it, for example End or "end". The parser reads a lowercase end as the closing keyword of a subgraph.
The same node is declared twice with different labels
Fix: Write A[Start] once, then refer to it as A. Repeating the label creates the shape twice and the second one usually wins.
Long labels stretch the diagram sideways
Fix: Put <br/> where you want the break, such as A[Long step<br/>second line], or shorten the label and move the detail into a note.
Two nodes look related but are not connected
Fix: Use --> between them, or wrap the second in a subgraph. Mermaid draws no edge unless you write one, so a step can look connected in your head and float on the page.
Flowchart FAQ
Can I make a Mermaid flowchart without writing code?
Yes. In TryMermaid, flowcharts can be built entirely on the drag-and-drop canvas. Every shape and connection you add is written to Mermaid flowchart code automatically, so you can switch to the code panel at any time.
What is the difference between graph and flowchart in Mermaid?
They draw the same kind of diagram. graph is the original keyword and flowchart is the newer one, which supports newer features such as extra shapes and edge options. Use flowchart for new diagrams.
How do I change the direction of a flowchart?
Change the direction after the keyword on the first line: flowchart TD draws top to bottom, LR left to right, BT bottom to top and RL right to left.
Why does my flowchart break when a label contains brackets?
Put the label in double quotes: A["Approve (with limits)"]. Mermaid reads brackets and parentheses as shape syntax, so an unquoted parenthesis inside a label is treated as the start of a new shape and the diagram fails to parse.
How do I put a line break inside a node label?
Add a line break with <br/> inside the label, for example A[Send the invoice<br/>to accounts]. Mermaid does not wrap long labels on its own, so a long step will stretch the whole diagram sideways until you break it yourself.
How do I group steps that belong to the same team?
Use a subgraph. Write subgraph Warehouse, list the steps inside it, then end. Mermaid draws a labelled box around those nodes, and arrows can still cross in and out of it, which is how you show one team handing over to another.
How do I change the colour of one box in a flowchart?
Define a style with classDef and apply it with class, for example classDef ok fill:#dcfce7 then class C ok. Use style NodeId fill:#eee for a one-off. Colours applied this way are kept in the exported PNG and SVG.
Can I show a Mermaid flowchart in a GitHub README?
Yes. GitHub renders Mermaid in Markdown files, so a flowchart in a README or a pull request appears as a diagram rather than as code. Put the code in a fenced block marked mermaid. GitLab and many documentation tools support it too.