Type Mermaid syntax, get a UML sequence diagram — live
sequenceDiagram, declare each participant on its own line, then write messages top to bottom: Shopper->>Website: Checkout. Solid arrows with filled heads (->>) are calls; dotted arrows (-->>) are replies. Blocks like loop and alt ... else ... end add repetition and branching. This maker renders as you type using the MIT-licensed Mermaid library, runs fully in your browser, and exports SVG or PNG with one click.
| Syntax | What it draws |
|---|---|
sequenceDiagram | Required first line |
participant P as Payments | Rectangle lifeline, custom display name |
actor U as User | Stick-figure lifeline for a human |
A->>B: Do work | Solid line, filled arrowhead — the standard call |
B-->>A: Done | Dotted line, filled head — reply or return value |
A->B: Fire and forget | Solid line, open head |
A--)B: Event | Dotted line, open head |
A-)B: Async send | Solid line, half (async) head |
A--)B: Async reply | Dotted line, half head |
activate A / deactivate A | Thin box showing A is busy (or wrap in +A+) |
Note over A,B: text | Note spanning lifelines (Note left of A, right of B also work) |
loop Every 30s | Repeating fragment |
alt Declined | Branching fragment |
opt Has coupon | Optional fragment |
par | Concurrent fragment |
critical Must succeed | Must-succeed section with fallbacks |
autonumber | Number every message 1, 2, 3… |
Six arrow types exist because the line style (solid or dotted) and head shape (filled, open, or half) each carry meaning — solid is a call, dotted is a response, half heads mark asynchronous messages. Most real diagrams use two or three of the six and stay perfectly readable.
A sequence diagram fixes two dimensions so you only think about one. Across the page: participants, in the order you declare them, each with a vertical lifeline. Down the page: time. Every message line you write becomes the next horizontal arrow, so reading top to bottom is reading the conversation in order. That constraint is the value — it makes ordering bugs visible, like a reply drawn before its request or a token used before it's issued.
Edit the code on the left and the preview redraws about 400 ms after you stop typing. The status line reports parse errors with position. When it looks right, grab the SVG (crisp in docs and wikis) or the 2x PNG (for slides and tickets). Both files are generated in your browser; nothing is uploaded. If you also need flowcharts or database schemas, the full suite renders those from the same editor.
The default diagram is a card-retry checkout. Count the pieces first: 3 participants (Shopper, Web app, Payments API), 8 messages, and 1 loop fragment containing 3 of those messages.
actor U as Shopper — human on the far leftU->>W: Checkout — solid filled arrow: a requestP-->>W: Declined — dotted arrow: a responseloop 2 retries ... end — the box around the retry exchangeBecause the two charge attempts sit inside the loop box, a reader sees at a glance that the flow repeats — no annotations needed. Delete the loop lines and the same messages render unboxed; structure comes entirely from keywords, so refactoring the diagram is refactoring text.
Start the first line with sequenceDiagram, list each participant on its own line, then write messages as arrows in top-to-bottom order: User->>API: Login. This maker renders Mermaid syntax live in your browser — no signup, no watermark — and exports SVG or PNG from a button. The same code renders on GitHub and GitLab if you keep it in a Markdown file.
The hyphen versus dotted line controls the line style and the bracket shape controls the head. A->>B draws a solid line with a filled arrowhead (a call); A-->>B draws a dotted line with a filled head (a reply or return); A->B is solid with an open head; A--)B is dotted with an open head; -) and --) draw async messages with half arrowheads. Most diagrams only need ->> for requests and -->> for responses.
Wrap the messages in a fragment keyword: loop Retry 3 times ... end repeats a block; alt Card declined ... else Card approved ... end branches; opt runs its block only sometimes. Also available: par for concurrency, critical for must-succeed sections, and break for interrupting scenarios. Every fragment opens with the keyword line and closes with end.
Participants go first, one declaration per line, in left-to-right order — order of declaration sets position on the page. Messages follow in the order they happen, since time runs top to bottom. actor U draws a stick figure for a human, participant S draws a rectangle for a system, and both accept an as alias to show a friendlier display name.
Use a sequence diagram when the interesting part is the order of messages between named parties — an API handshake, an OAuth flow, a support escalation. Use a flowchart when the interesting part is the branching logic inside one process. Sequence diagrams answer who talked to whom and in what order; flowcharts answer what happens next.