Mermaid turns plain text into real diagrams. One keyword declares the diagram type, then each line is a statement the renderer draws for you — no dragging boxes, no aligning arrows. That makes it the fastest way to get a sequence, ER, or class diagram into a README or a design doc, and the easiest one to update in a pull request. Here's the syntax that covers 95% of real-world diagrams, plus the handful of mistakes that break almost every first render.
Every Mermaid block starts with a diagram type keyword on the first line. Everything after it is the diagram body, one statement per line:
flowchart TD
A[Start] --> B{Is it written in text?}
B -- Yes --> C[Use Mermaid]
B -- No --> D[Draw it by hand]
That's the whole mental model. The keyword says what kind of picture; the lines say what's in it. Mermaid (MIT-licensed, free for anything including commercial use) renders it client-side, which is why GitHub, GitLab, and Notion display Mermaid blocks in markdown files without any plugin. The same block pasted into the Mermaid diagram suite renders live and exports SVG or PNG.
The most useful type keywords: flowchart (boxes and arrows), sequenceDiagram (interactions over time), erDiagram (database entities), classDiagram (code structure), and gantt (timelines). Flowcharts and Gantt charts have their own dedicated builders here — the flowchart maker and Gantt chart maker — so this guide focuses on the three text-first diagram types where Mermaid is the de facto standard.
Sequence diagrams show messages between actors over time. The skeleton:
sequenceDiagram
actor U as User
participant A as App
participant S as Auth Server
U->>A: Tap "Sign in"
A->>S: POST /login
activate S
S-->>A: 200 OK + token
deactivate S
A-->>U: Show dashboard
loop Every page load
A->>S: Validate token
S-->>A: valid
end
Read the arrows like this:
| Line | Draws |
|---|---|
A->>B: msg | Solid arrow, filled head — a request |
A-->>B: msg | Dashed arrow — a response or reply |
A->B: msg / A-->B: msg | Thin open-head variants |
activate B … deactivate B | Activation bar on B's lifeline while it works |
A->>+B: msg then A->>-B: msg | Shorthand: activate on send, deactivate on return |
loop … end | Loop frame around the messages inside |
alt … else … end | Branch frame (if/else) |
opt … end / par … end | Optional / parallel frames |
Note over A,B: text | A note spanning participants |
actor draws a stick figure, participant a box; both take an as alias so your code says S and readers see "Auth Server". The sequence diagram maker runs this live with a cheatsheet alongside the editor.
ER diagrams in Mermaid are relationship-first. Each line connects two entities with crow's-foot notation on the line itself:
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE_ITEM : contains
PRODUCT ||--o{ LINE_ITEM : "appears in"
CUSTOMER {
string email PK
string name
}
ORDER {
int id PK
string customer_email FK
date placed_on
}
The cardinality marks are the part worth memorizing — each side of the dashed line gets one:
| Mark | Meaning |
|---|---|
|| | Exactly one |
o| | Zero or one |
}o | Zero or more |
}| | One or more |
So CUSTOMER ||--o{ ORDER reads left to right: one customer, zero-or-many orders. Attribute blocks go under an entity by name, one attribute per line as type name key, where key is PK, FK, or UK for unique. Try your schema in the ER diagram maker — it keeps the crow's-foot table on screen while you type.
Class diagrams describe code structure: classes, their members, and how they relate. Members use visibility symbols borrowed from UML:
classDiagram
class Account {
+String owner
-int balance_cents
+deposit(int amount) bool
-validate() void
}
Account <|-- SavingsAccount
Account <|-- CheckingAccount
Bank "1" *-- "many" Account : holds
Statement o-- Account : summarizes
| Symbol | Visibility | Relationship line | Meaning |
|---|---|---|---|
+ | Public | A --|> B | Inheritance (B is parent) |
- | Private | A *-- B | Composition (B owned by A) |
# | Protected | A o-- B | Aggregation (B referenced by A) |
~ | Package/internal | A --> B | Dependency (uses) |
$ | Static (after symbol) | A "1" -- "0..*" B | Multiplicity labels |
The class diagram maker has the full member and relationship table next to a live editor.
Almost every broken diagram comes down to one of five things:
sequenceDiagram is one word, erDiagram is camelCase, flowchart TD needs a direction.A["Login (retry)"] instead of A[Login (retry)].-->; sequence diagrams need ->> for messages. ER diagrams don't use arrows at all — cardinality marks joined by a dashed line.end lines. Frames close with end alone. end # comment breaks the parser in several versions.The fastest fix loop: paste the block into the live suite editor, and the error view points at the failing line. Then re-export or copy the corrected text back into your doc.
Live editor, sequence / ER / class cheatsheets, SVG and PNG export — all client-side, no signup.
Open the Mermaid Diagram Suite →Mermaid syntax is plain text that describes a diagram line by line. You open with a diagram type keyword (sequenceDiagram, erDiagram, classDiagram, flowchart TD) and then write statements like Alice ->> Bob: Login request. The renderer turns each line into boxes, arrows, and labels automatically. Because it's text, diagrams live happily in version control, code review, and README files — GitHub, GitLab, and Notion render Mermaid blocks natively.
Start with the line sequenceDiagram, list participants if you want friendly names, then write messages as Source ->> Target: label. Solid arrows with a filled head are ->>, dashed replies are -->>, and activation bars are added with activate/deactivate or the plus/minus shorthand. Frames like loop, alt/else, and opt group messages into the boxes readers expect from UML.
Open with erDiagram, then write relationship lines in the pattern ENTITY1 ||--o{ ENTITY2 : labels. The two crow's-foot pieces before and after the dashed line set each side's cardinality: || is exactly one, o| is zero or one, }o is zero or more, }| is one or more. Add attributes under an entity with a block: entity name, then lines like string email PK.
Five mistakes cause almost every broken render: a missing or misspelled diagram type on the first line, special characters inside node labels (wrap the label in quotes), using arrows where the syntax expects cardinality marks or plain lines, text after the closing keyword on end lines, and tab/space mixups inside member blocks. Paste the block into a live editor and the error line is usually highlighted.
Yes. Mermaid is open source under the MIT license, free for commercial use, and renders client-side in the browser — your diagram text never has to leave your machine. GitHub, GitLab, and Notion support it out of the box, and most documentation tools (Obsidian, Joplin, Confluence via plugins) do too.
Related tools: