Mermaid live diagram editor and generator

Turn text into a diagram with the live editor below. Explore the guide and examples to choose the right diagram for a process, a technical explanation or a project plan.

What is Mermaid?

Mermaid  is a diagramming language and renderer: you describe steps, people or relationships in text, and it draws the diagram. For example, Review --> Publish connects two nodes with an arrow. You write the relationships; Mermaid handles the layout.

This approach is often called diagrams as code. The source is ordinary text that you can search, copy and keep in version control alongside the document it explains. You do not need to write JavaScript to use it. Mermaid draws what you describe; it does not inspect your application or verify that a process is correct.

Choose a diagram for the question you need to answer

A useful diagram has a clear purpose. Decide what the reader needs to understand before choosing shapes or colors.

For other questions, a mind map can organize ideas, a timeline can summarize events, and a Git graph can explain a branching strategy. Start with the Mermaid syntax overview  when choosing a family outside these examples. Each family has its own grammar; changing only the first line does not convert one diagram into another.

Five examples to adapt

Each tab contains a complete diagram and explains a modeling choice. Copy the code into a Mermaid editor to render it; the opening diagram declaration belongs in the source, while Markdown’s surrounding backticks do not.

flowchart TD
    Submit["Submit expense"] --> Check{"Receipt attached?"}
    Check -->|Yes| Review["Manager review"]
    Check -->|No| Fix["Attach receipt"]
    Fix --> Check
    Review --> Decision{"Approved?"}
    Decision -->|Yes| Pay["Reimburse employee"]
    Decision -->|No| Reject["Explain rejection"]

sequenceDiagram
    participant Browser
    participant API
    participant Cache
    participant DB as Database
    Browser->>API: GET /products/42
    API->>Cache: Look up product 42
    alt Cache hit
        Cache-->>API: Product
    else Cache miss
        Cache-->>API: Not found
        API->>DB: Read product 42
        DB-->>API: Product
        API->>Cache: Store product
    end
    API-->>Browser: 200 OK with product

stateDiagram-v2
    [*] --> Open
    Open --> InProgress: Assign
    InProgress --> Waiting: Request information
    Waiting --> InProgress: Receive reply
    InProgress --> Resolved: Provide solution
    Resolved --> Open: Reopen
    Resolved --> Closed: Confirm resolution
    Closed --> [*]

erDiagram
    CUSTOMER ||..o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    CUSTOMER {
        int id PK
        string email
    }
    ORDER {
        int id PK
        int customer_id FK
    }
    ORDER_LINE {
        int order_id PK, FK
        int line_number PK
        int quantity
    }

gantt
    title Documentation release
    dateFormat YYYY-MM-DD
    excludes weekends
    section Preparation
    Outline       :outline, 2026-11-02, 2d
    Draft         :draft, after outline, 3d
    section Publication
    Review        :review, after draft, 2d
    Publish       :milestone, after review, 0d

Where Mermaid helps, and where it gets in the way

Mermaid is a good fit for diagrams that change with a specification, support article or codebase:

• Changes are reviewable. A text diff can show that a step or relationship changed. Keep one relationship per line to make those reviews easier.
• Updates can live beside the explanation. Store the diagram source with the document and review both in the same change. This helps maintenance, but does not keep the diagram current automatically.
• You spend less time arranging shapes. Automatic layout is convenient for small process and interaction diagrams, especially when labels change often.

The tradeoffs matter just as much:

• Precise placement is limited. Adding a connection can rearrange the drawing. If exact spacing, freehand annotation or a carefully composed illustration matters most, a visual drawing tool is usually a better fit.
• Text editing has a learning curve. Missing punctuation or using another diagram family’s syntax can stop rendering. Start with a small working example and add one idea at a time.
• Large diagrams become difficult to read. More nodes and crossed lines can obscure the point even when the source is valid. Split an overview from detailed workflows instead of shrinking everything onto one page.
• Portability needs checking. A documentation platform may use another Mermaid version or different configuration. Test on the destination, especially when using recent syntax, icons or styling.

Put a diagram in a README or document

On a platform with Mermaid support, wrap the source in a fenced Markdown block labeled mermaid:

```mermaid
flowchart LR
    Draft --> Review --> Publish
```

GitHub’s diagram guide  explains supported locations and how to check its Mermaid version. Other Markdown systems may need a plugin; an ordinary code fence alone does not make every renderer draw a diagram.

For slides or a document that cannot render Mermaid, insert an image and keep the source file alongside it. The image is a snapshot: changing the source later will not update an already inserted image. Review the result at its final display size, where long labels and small text can become unreadable.

Make the diagram useful to someone else

Give it a scope: “How a cache miss is handled” is more informative than “System architecture” for the API example above. Use verbs for actions, nouns for entities, and labels on decision paths. Include the failure or recovery path that readers are most likely to need.

Explain any important rule in nearby prose, and avoid making color the only way to distinguish outcomes. Mermaid’s accessibility options  include accTitle and accDescr for an accessible title and description. When publishing a diagram as an image, add suitable alternative text in the destination document too; a PNG does not carry Mermaid’s SVG accessibility structure.