Kostenlos · Ohne Anmeldung · Für .mmd-Dateien

Mermaid Sequenzdiagramm Editor

Ein Sequenzdiagramm zeigt Nachrichten zwischen Beteiligten in der Reihenfolge, in der sie passieren; die Zeit läuft dabei nach unten. Nimm es, wenn die Frage lautet, wer wen in welcher Reihenfolge aufruft und was zurückkommt — API-Aufrufe, Anmeldeabläufe, Wiederholungen. Geht es um die Verzweigungslogik innerhalb einer Komponente, passt ein Flussdiagramm besser.

Im Editor öffnen →Zum Leitfaden

OAuth 2.0 Authorization Code Flow

Der Musterfall für ein Sequenzdiagramm: vier Beteiligte, eine Weiterleitung, die der Nutzer nicht sieht, und ein Token-Tausch, der zwingend zwischen Servern stattfinden muss. Fließtext beschreibt das schlecht, und ein Flussdiagramm kann die Reihenfolge überhaupt nicht zeigen.

sequenceDiagram
    autonumber
    participant N as Nutzer
    participant B as Browser
    participant A as Auth-Server
    participant API as Ressourcen-API

    N->>B: Auf "Anmelden" klicken
    B->>A: GET /authorize?client_id&redirect_uri
    A-->>B: Weiterleitung zur Anmeldeseite
    N->>A: Zugangsdaten absenden
    A-->>B: 302 an redirect_uri mit Code
    B->>API: POST /token mit Code
    API->>A: Code tauschen (Server zu Server)
    A-->>API: access_token und refresh_token
    API-->>B: Sitzungscookie setzen
    B-->>N: Angemeldet

Im Editor öffnen

Durchgearbeitete Beispiele

1. Zwei Beteiligte, ein Hin und Her

`->>` ist ein durchgezogener Pfeil mit gefüllter Spitze, üblicherweise eine Anfrage. `-->>` ist gestrichelt, üblicherweise die Antwort. Das ist Konvention und wird nicht erzwungen — sie zu brechen macht Diagramme aber schwer überfliegbar.

sequenceDiagram
    Client->>Server: GET /bestellungen
    Server-->>Client: 200 mit Bestellliste

Im Editor öffnen

2. Kurznamen und Aktivierungsbalken

`participant X as Langer Name` hält die Pfeile kurz und den Kasten lesbar. `activate` und `deactivate` zeichnen den Balken, der zeigt, wie lange ein Beteiligter beschäftigt ist — praktisch, um einen langsamen Aufruf sichtbar zu machen.

sequenceDiagram
    participant API as Bestell-API
    participant DB as Postgres

    API->>DB: SELECT * FROM bestellungen
    activate DB
    DB-->>API: 4.200 Zeilen
    deactivate DB
    API->>API: Antwort serialisieren

Im Editor öffnen

3. Verzweigen mit alt und opt

`alt`/`else` ist eine Entweder-oder-Entscheidung, `opt` ein Schritt, der auch ausfallen kann. Jeder dieser Blöcke muss mit `end` geschlossen werden — ein offener Block ist der häufigste Fehler in Sequenzdiagrammen, und Mermaid meldet ihn am Dateiende statt beim Block.

sequenceDiagram
    participant K as Kasse
    participant Z as Zahlungsdienstleister

    K->>Z: 49,90 EUR autorisieren
    alt autorisiert
        Z-->>K: Freigabecode
        K->>K: Bestellung als bezahlt markieren
    else abgelehnt
        Z-->>K: Ablehnungsgrund
        K->>K: Reservierten Bestand freigeben
    end
    opt Betrugsrisiko hoch
        K->>K: Zur manuellen Prüfung vormerken
    end

Im Editor öffnen

4. Wiederholschleifen und Notizen

`loop` klammert wiederholte Nachrichten, und eine `Note over` ist der richtige Ort für das, wonach ein Leser sonst fragt — ein Timeout, eine Obergrenze, der Grund für die Begrenzung.

sequenceDiagram
    participant W as Worker
    participant S as Suchindex

    Note over W,S: Höchstens 5 Versuche, danach Dead-Letter-Queue
    loop bis zu 5 Versuche
        W->>S: PUT /dokumente/42
        S-->>W: 503 Service Unavailable
        W->>W: Exponentiell warten
    end
    W->>W: In Dead-Letter-Queue verschieben

Im Editor öffnen

5. Parallele Arbeit und Selbstaufrufe

`par` zeigt gleichzeitig laufende Arbeit — genau das, was Fließtext am schlechtesten beschreibt. Ein Pfeil von einem Beteiligten zu sich selbst ist ein legitimer Weg, interne Arbeit zu zeigen, ohne eine erfundene Komponente einzuführen.

sequenceDiagram
    participant B as Bestelldienst
    participant M as Mailversand
    participant R as Rechnungsdienst
    participant A as Auswertung

    B->>B: Transaktion festschreiben
    par Kunde benachrichtigen
        B->>M: Bestätigungsmail senden
    and Belege erzeugen
        B->>R: Rechnungs-PDF erstellen
    and Kennzahlen erfassen
        B->>A: Ereignis bestellung_erstellt melden
    end
    B-->>B: 201 an den Aufrufer zurückgeben

Im Editor öffnen

Syntaxreferenz für Sequenzdiagramme

Sequenzdiagramme haben ihr eigenes Pfeilvokabular. Nichts davon funktioniert in einem Flussdiagramm, und Flussdiagramm-Pfeile bedeuten hier meist nicht das, was man erwartet.

Syntax	Bedeutung
sequenceDiagram	Öffnet das Diagramm. Groß-/Kleinschreibung zählt — `sequencediagram` scheitert.
participant A	Deklariert einen Beteiligten und legt die Reihenfolge von links nach rechts fest.
participant A as Name	Kurzname in den Pfeilen, voller Name im Kasten.
actor A	Wie participant, aber als Strichmännchen gezeichnet.
A->>B: Text	Durchgezogener Pfeil mit gefüllter Spitze. Üblicherweise eine Anfrage.
A-->>B: Text	Gestrichelter Pfeil mit gefüllter Spitze. Üblicherweise eine Antwort.
A->B: Text	Durchgezogene Linie ohne Pfeilspitze.
A-)B: Text	Offene Pfeilspitze — üblicherweise eine asynchrone Nachricht.
A-xB: Text	Pfeil mit Kreuz am Ende — üblicherweise eine verlorene Nachricht.
activate A / deactivate A	Aktivierungsbalken zeichnen, solange A beschäftigt ist.
alt Bed. / else Bed. / end	Sich gegenseitig ausschließende Zweige.
opt Bed. / end	Ein Block, der auch entfallen kann.
loop Text / end	Wiederholte Nachrichten.
par Text / and Text / end	Gleichzeitig laufende Zweige.
Note over A,B: Text	Notiz über mehrere Beteiligte. Auch `Note left of` und `Note right of`.
autonumber	Nummeriert jede Nachricht automatisch.

Sechs Fehler, die Sequenzdiagramme zerlegen

Nachgestellt mit Mermaid 11.12.2. Füge die fehlerhafte Fassung in den Editor ein, um die genaue Meldung zu sehen; die korrigierte rendert.

Was du siehst

Parse error in der letzten Zeile des Diagramms

Warum

Ein geöffneter und nie geschlossener Block. `alt`, `opt`, `loop` und `par` brauchen alle ein passendes `end`. Mermaid merkt es erst, wenn die Eingabe ausgeht, und beschuldigt deshalb die letzte Zeile statt den vergessenen Block.

Lösung

Öffnende Blöcke gegen `end` zählen. Steht der Fehler in der letzten Zeile, ist es fast immer das.

Fehlerhaft

sequenceDiagram
    K->>S: Anfrage
    alt erfolgreich
        S-->>K: Zusage

Korrigiert

sequenceDiagram
    K->>S: Anfrage
    alt erfolgreich
        S-->>K: Zusage
    end

Was du siehst

Parse error in einer Nachrichtenzeile

Warum

Eine Nachricht ohne Doppelpunkt. Jeder Pfeil braucht `: Text` dahinter, auch wenn der Text offensichtlich wirkt.

Lösung

Doppelpunkt und Beschriftung ergänzen.

Fehlerhaft

sequenceDiagram
    Kunde->>Shop Bestellung

Korrigiert

sequenceDiagram
    Kunde->>Shop: Bestellung

Was du siehst

No diagram type detected matching given configuration

Warum

Falsche Groß-/Kleinschreibung des Schlüsselworts. Mermaids Diagrammtypen unterscheiden Groß- und Kleinschreibung, und `sequencediagram` ist nicht dasselbe Token wie `sequenceDiagram`.

Lösung

Das D großschreiben.

Fehlerhaft

sequencediagram
    A->>B: Hallo

Korrigiert

sequenceDiagram
    A->>B: Hallo

Was du siehst

Trying to inactivate an inactive participant (B)

Warum

Ein `deactivate` ohne passendes `activate`. Anders als die Parse-Fehler oben ist das eine inhaltliche Prüfung, deshalb ist die Meldung ein lesbarer Satz statt einer Token-Liste — das Diagramm rendert trotzdem nicht.

Lösung

Jedes `deactivate` mit einem `activate` paaren, oder beide weglassen und die Pfeile für sich sprechen lassen.

Fehlerhaft

sequenceDiagram
    A->>B: Anfrage
    deactivate B

Korrigiert

sequenceDiagram
    A->>B: Anfrage
    activate B
    B-->>A: Antwort
    deactivate B

Was du siehst

Parse error nach einem Beteiligten-Namen

Warum

Ein Doppelpunkt in einer participant-Zeile. Die Deklaration nimmt einen Namen oder einen `as`-Kurznamen entgegen, sonst nichts.

Lösung

`as` für den Anzeigenamen verwenden.

Fehlerhaft

sequenceDiagram
    participant API: Bestelldienst
    API->>DB: Abfrage

Korrigiert

sequenceDiagram
    participant API as Bestelldienst
    API->>DB: Abfrage

Was du siehst

`end` erscheint als Beteiligter, statt den Block zu schließen

Warum

`end` ist auch hier ein Schlüsselwort. Nicht die Einrückung entscheidet, was einen Block schließt, sondern das Token — ein Beteiligter namens `end` kollidiert also mit dem Blockabschluss.

Lösung

Nie einen Beteiligten `end` nennen. Großschreiben oder umbenennen.

Fehlerhaft

sequenceDiagram
    A->>end: abschließen

Korrigiert

sequenceDiagram
    A->>Endpunkt: abschließen

Hinweise zum Rendern

Gemessen an Mermaid 11.12.2, so wie diese Seite es einsetzt. Sequenzdiagramme verhalten sich in zwei Punkten anders als jeder andere Typ hier.

Die Breite bestimmt die Zahl der Beteiligten, nicht die Zahl der Nachrichten

Drei Nachrichten zwischen zwei Beteiligten ergeben eine viewBox von etwa 450×309. Vierzig Nachrichten zwischen denselben zwei Beteiligten ergeben 450×2011 — die Breite hat sich nicht bewegt. Weitere Beteiligte verbreitern das Diagramm, weitere Nachrichten verlängern es nur. Praktisch heißt das: Ab etwa sechs Beteiligten wird ein Sequenzdiagramm auf einem Laptop unlesbar breit, lange bevor die Zahl der Nachrichten ein Problem wäre.

Sequenzdiagramme haben einen negativen viewBox-Ursprung

Jeder andere Diagrammtyp auf dieser Seite beginnt seine viewBox bei `0 0`. Sequenzdiagramme beginnen bei `-50 -10` — Mermaid reserviert Platz links und oben für die Kästen der Beteiligten. Das ist wichtig, wenn du das exportierte SVG weiterverarbeitest: naiver Zuschnitt, der einen Nullpunkt annimmt, schneidet den linken Beteiligten ab.

Der PNG-Export funktioniert hier direkt

Sequenzdiagramme zeichnen ihre Beschriftungen als gewöhnlichen SVG-Text statt als eingebettetes HTML — anders als Fluss-, Klassen-, Zustands- und ER-Diagramme. Der Browser kann sie deshalb unmittelbar rastern, und das exportierte PNG entspricht pixelgenau dem Bildschirm: kein erneutes Rendern, keine Verschiebung in der Typografie.

Etwa 45 px Höhe pro Nachricht

Nützlich, um vorab abzuschätzen, ob ein Diagramm auf eine Folie passt. Zwanzig Nachrichten sind rund 900 Pixel hoch, und das ist ungefähr die Grenze, bis zu der ein Screenshot ohne Scrollen lesbar bleibt.

Das Theme ändert Farben, niemals das Layout

Dasselbe Diagramm mit hellem und dunklem Theme ergibt eine identische viewBox. Die Kästen der Beteiligten können beim Themewechsel also weder verrutschen noch abgeschnitten werden.

Wann etwas anderes besser passt

Wenn die meisten Nachrichten von einem Beteiligten zu sich selbst gehen, beschreibst du einen Algorithmus und kein Gespräch — dann liest sich ein Flussdiagramm besser.

Wenn du anfängst, `alt`-Blöcke in `alt`-Blöcke zu schachteln, ist die Verzweigung dem Format entwachsen. Sequenzdiagramme zeigen einen Weg durch ein System hervorragend und alle Wege durch ein System sehr schlecht. Zeichne hier den Normalfall und pack die Fehlerbehandlung in ein eigenes Diagramm.

Und wenn eigentlich zu zeigen ist, welche Komponenten existieren und wie sie zusammenhängen — statt in welcher Reihenfolge sie reden —, hilft kein Sequenzdiagramm. Das ist ein Architekturbild, und Mermaids Flussdiagramm mit Subgraphen passt besser dazu.

Andere Diagrammtypen

Geschrieben von Dominik Malsch · Zuletzt aktualisiert: 8. September 2026

Editor öffnen →