Mermaid diagram examples you can copy

These mermaid diagram examples are short, complete diagrams you can copy when you need a shape and a reason, not a lecture. Each one below is a situation I would actually put in a repo, with the reason that shape fits, and the source is the part you keep.

Six is enough. A gallery of twenty-five fences with a caption under each one teaches you how to scroll. These six teach you how to choose. Flowchart, sequence, class, ER, state, and a mind map. If you already know which type you need, the diagram index and the template library are the full set. If you don't know the type, read the "why" lines and stop when one of them sounds like your ticket.

The cheat sheet is the token list I keep open while I adapt these. I'm not repeating it under every fence. Change the nouns, keep the shape, delete anything that isn't true of your system.

Copy the shape that matches the question

I pick a diagram by the question, then I look for an example. "What do we do if the severity is high?" is a flowchart. "Who do we call, and what comes back?" is a sequence. "What types exist?" is a class diagram. "What rows exist?" is an ER diagram. "What condition is this thing in?" is a state diagram. "What topics are even on the table?" is a mind map. If I pick the example first, I bend the question until it fits the picture I liked.

What a Mermaid diagram is is the orientation if the word diagram is still fuzzy. The syntax that shows up in every type is the page for quotes, ids, and the word end. Use that when an example fails after you edited it. The failure is usually yours. The examples on this page parse.

I commit the fence next to the code it describes. I don't commit a PNG of the example and throw the text away. The next example you need is an edit of this one, and pixels don't edit.

A policy wants a flowchart

A flowchart is the right example when there is a question and the answers go to different work. An incident page is that. High severity wakes someone. Lower severity waits for the morning queue. Both paths end by writing a note, because we don't want a page that vanished with no record. The join is the claim. If a high-severity page should skip the note, the join is a lie and you should delete it.

flowchart TD
    filed([Incident filed]) --> sev{Severity high?}
    sev -->|Yes| page[Page the primary]
    sev -->|No| queue[Leave it for the morning]
    page --> note[Write the timeline note]
    queue --> note

Top to bottom, because the question should sit above the two answers. The diamond is labeled on both exits. note has two parents on purpose. I didn't add Slack, a status page, or a postmortem box. Those might be real later. They aren't this decision. Flow charts go into the symbols and the judgment if this shape is the one you're going to maintain. The flowchart syntax page is the token reference if you want a document shape or a subgraph and this example feels too plain.

Don't name the last node end. I used note. If your policy's last step is literally called "end of incident," the id can be close and the label can say "Close the incident." The word end is already busy closing subgraphs.

A call wants a sequence

A sequence is the right example when the reader must see the reply, not just the hop. Here a worker asks the feature service whether a flag is on, and the service answers yes or no. The caller does different work. A flowchart could hold the yes and no. It would hide that the answer comes from a different process than the question.

sequenceDiagram
    autonumber
    participant Worker as Worker
    participant Flags as Flags
    Worker->>Flags: Is billing v2 on?
    alt on
        Flags-->>Worker: Yes
        Worker->>Worker: Use the new path
    else off
        Flags-->>Worker: No
        Worker->>Worker: Use the old path
    end

Workers and flags are declared first, so the reply doesn't invent the cast. Solid going out, dotted coming back. The self-arrows are a little ugly and they're honest: the choice is local after the answer arrives. I don't draw a third participant called "New path." A path isn't a speaker.

The sequence diagram page has the other arrow forms and the loop block, which this example doesn't need. An example focused only on sequence diagrams is the right hop if you want more conversations and not the other five shapes on this page. I keep message text short. The flag name can live in the message because it is the content. The JSON body of the flag service should not.

end closes the alt. It is not a participant. If you add a participant named End to mean "the old system," the block structure and the name will fight. Call that system Legacy.

A paste I had to fix last month dropped the colon: Worker->>Flags Is billing v2 on? with no colon after Flags. The arrows looked finished. The line is not a message until the colon is there. I also watched someone "repair" that by deleting the alt and drawing both paths as unconditional arrows, which parses and lies. The flag is a question. Keep the alt. Put the colon back. If the question mark in the message bothers you, it is fine inside the message text after the colon. It is not fine inside an unquoted flowchart label, which is a different example and a different failure.

Types in code want a class diagram

A class diagram is the right example when the review is about types and how they hold each other, not about rows and not about the order of calls. A notification can be sent through a channel. An email channel is a kind of channel. The notification doesn't own the channel's lifetime. The channel outlives any one message.

classDiagram
    class Notification {
      +string subject
      +send()
    }
    class Channel {
      +string name
      +deliver()
    }
    class EmailChannel {
      +string fromAddress
    }
    Channel <|-- EmailChannel
    Notification "1" --> "*" Channel : uses

The hollow triangle points at Channel, the parent. EmailChannel is the child. I say that while I type, because EmailChannel <|-- Channel parses and teaches the wrong hierarchy. "1" --> "*" is quoted on purpose. A bare star is read as composition syntax and the line fails. The verb uses is there so nobody decides the arrow is ownership. Ownership would be *--, and it would be the wrong claim. The channel remains if the notification is deleted.

I left methods almost empty. +send() and +deliver() mark behavior worth naming. I didn't list getters. A class diagram that lists getters is a dump of the file, and the inheritance gets lost under the noise. Add a field when a review might reject it. fromAddress is that field. A createdAt on Notification usually isn't, not on this picture.

Rows want an ER diagram

An ER diagram is the right example when the question is cardinality and keys. A reader saves articles. The save is a row, because we keep the time they saved it. That makes a join entity, not a many-to-many line with nowhere to put the timestamp.

erDiagram
    READER ||--o{ SAVED : keeps
    ARTICLE ||--o{ SAVED : "appears in"
    READER {
        string id PK
        string email UK
    }
    ARTICLE {
        string id PK
        string title
    }
    SAVED {
        string readerId PK, FK
        string articleId PK, FK
        string savedAt
    }

One reader, many saves. One article, many saves. The pair of foreign keys is the primary key, so a reader saves an article once. savedAt is why SAVED exists as a box. If you don't store anything but the pair, you might still want the entity, and you should be able to say why. "The diagram looked empty" is not a why.

I didn't draw a direct line from READER to ARTICLE. The direct line would hide savedAt. I also didn't list the article body. The body is a column in the product and a distraction in this picture. The feet are the picture.

email is UK, not PK. The id is what other tables store. If you use the email as the primary key, change the mark and keep the feet. The feet don't care which column is the key. They care which side is the many.

One object's life wants states

A state diagram is the right example when one noun sits in conditions and the arrows are events that move it. A pull request is draft, then in review, then merged, or it goes back to draft. Merged is terminal in this small machine. I am not drawing the reviewers. I'm drawing the request.

stateDiagram-v2
    [*] --> Draft
    state "In review" as rev
    Draft --> rev : open
    rev --> Draft : request changes
    rev --> Merged : merge
    Merged --> [*]

[*] is the start and the stop. rev is the id, and "In review" is the label, because the id can't comfortably be two words. The loop back to Draft is why this isn't a flowchart with the draft box copied twice. There is one Draft. Changes return you to it.

I didn't add a "closed" state beside Merged. If abandon is real, add rev --> Abandoned : abandon and decide whether Abandoned is terminal. Don't add it because state diagrams look more serious with more bubbles. A serious diagram is a short one that matches the enum in the code. If the enum and the picture disagree, the picture is a bug, even when it parses.

Event names are verbs the product uses. "open," "request changes," "merge." I don't write "user clicks button" on the arrow. The click is a client detail. The event is the transition.

The mistake I make when I copy this one is adding a second Draft so the "request changes" arrow has somewhere new to land. That second box parses, and it claims there are two drafts. There aren't. Point the arrow back at Draft. If the product really has "changes requested" as its own condition, with different allowed events than Draft, then it earns its own state and its own id. Don't clone Draft to make the layout look like a line. The loop is the layout.

A naming session wants a mind map

A mind map is the right example when you are still naming the pieces and there is no order, no cardinality, and no call. An on-call handoff has topics. It doesn't have a yes branch yet. Forcing a flowchart this early invents a policy you haven't decided.

mindmap
  root((Handoff))
    Now
      Paging
      Mitigation
    Next
      Owner
      Ticket
    Later
      Writeup
      Followups

The root is the topic. Children are indented two spaces. Their children are indented two more. There are no arrows, and adding --> will not create a tasteful edge. It will create a broken map or a nonsense label. Now, Next, and Later are siblings. They are not a sequence the renderer enforces. Readers will still try to read them in order, which is why I chose words that admit an order without pretending the map is a process. If the order becomes a rule, I move that part to the flowchart at the top of this page and I leave the map as an index.

I don't mix shapes on the branches. The root is a circle so the eye finds it. Everything else is plain text. A mind map full of diamonds looks like a flowchart that lost its arrows, which is the failure mode this example exists to avoid.

Where the rest of the set lives

These six are starters, not a standard library. The diagram index has the types I didn't draw here, including Gantt, journey, and git. The template library has longer files, a login flow and a shop schema among them, which you should delete down to the boxes you have. Adopting a template whole is how a diagram starts describing a company that isn't yours.

When you edit an example, keep its reason. If you add a foreign key to the class diagram, you've started an ER diagram in the wrong file. If you add a reply to the flowchart, you've started a sequence. Split the fence. Two pictures and a sentence between them is easier to review than one picture with a footnote that says "ignore the arrows that look like calls."

I paste an example into the editor and change one noun before I add a node. If the picture stops being true after that one change, I wanted a different example, not a bigger one. The editor is free to open. There's no signup standing between you and the preview. Share the text if someone needs the same picture for a few minutes, and still commit the fence if the picture is going to live.

Open the editor with the example that matched your question, replace the nouns, and delete every node you can't defend in the pull request. A shorter copy that is true beats a complete copy of a system you don't run.