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

Mermaid Flussdiagramm Editor

Ein Flussdiagramm zeigt, wie die Steuerung durch einen Prozess läuft: Schritte, Verzweigungen und die Stellen, an denen sie wieder zusammenlaufen. Nimm es, wenn die Reihenfolge der Entscheidungen das Interessante ist — eine Deployment-Pipeline, ein Request-Pfad, ein Freigabeweg. Geht es darum, wer wann mit wem spricht, passt ein Sequenzdiagramm besser.

Im Editor öffnen →Zum Leitfaden

Eine CI-Pipeline mit zwei Fehlerpfaden

So fangen die meisten Flussdiagramme an: ein linearer Happy Path mit Entscheidungsknoten, die daraus ausbrechen. Beachte die Anführungszeichen beim letzten Knoten — Klammern in einer Beschriftung müssen zitiert werden, und genau das ist der häufigste Fehler in Flussdiagrammen.

flowchart TD
    Push[Push auf main] --> Lint[Linting und Typprüfung]
    Lint --> Test{Tests bestanden?}
    Test -->|nein| Fail[Autor in Slack benachrichtigen]
    Test -->|ja| Build[Container-Image bauen]
    Build --> Scan{CVE-Scan sauber?}
    Scan -->|nein| Block["Release blockieren (Prüfung nötig)"]
    Scan -->|ja| Deploy[Auf Produktion ausrollen]
    Deploy --> Smoke[Smoke-Tests ausführen]
    Smoke --> Fertig[Release abgeschlossen]

Im Editor öffnen

Durchgearbeitete Beispiele

1. Das kleinste sinnvolle Flussdiagramm

Zwei Knoten und ein Pfeil. `TD` heißt von oben nach unten; `LR` ergibt von links nach rechts, was für alles, was breiter als hoch ist, meist besser aussieht.

flowchart TD
    Anfrage[Anfrage geht ein] --> Antwort[Antwort verschickt]

Im Editor öffnen

2. Eine Entscheidung mit beschrifteten Zweigen

Geschweifte Klammern erzeugen eine Raute. Der Text zwischen den senkrechten Strichen beschriftet die Kante, nicht den Knoten — dieser Unterschied wird im Fehlerabschnitt weiter unten wichtig.

flowchart TD
    Start[Anfrage empfangen] --> Auth{Token gültig?}
    Auth -->|ja| Handler[Handler ausführen]
    Auth -->|nein| Ablehnen[401 zurückgeben]
    Handler --> Fertig[200 zurückgeben]

Im Editor öffnen

3. Knotenformen, die etwas bedeuten

Die Form ist die billigste Art, einem Flussdiagramm Information hinzuzufügen. Abgerundet für Anfang und Ende, Raute für eine Entscheidung, Zylinder für einen Datenspeicher.

flowchart LR
    Start([Job eingeplant]) --> Lesen[(Aus Postgres lesen)]
    Lesen --> Pruefen{Zeilen vorhanden?}
    Pruefen -->|keine| Ende([Mit 0 beenden])
    Pruefen -->|einige| Arbeit[/Zeilen transformieren/]
    Arbeit --> Schreiben[(Nach S3 schreiben)]
    Schreiben --> Ende

Im Editor öffnen

4. Subgraphen zur Gruppierung nach Zuständigkeit

Ein Subgraph zeichnet einen Kasten um zusammengehörige Knoten. Am nützlichsten ist nicht die Gruppierung nach Prozessphase, sondern nach Verantwortung — welches Team oder welcher Dienst wofür zuständig ist. Dann werden die Übergaben sichtbar.

flowchart TD
    subgraph client [Browser]
        UI[Formular abgeschickt]
    end
    subgraph api [Bestelldienst]
        Pruefen[Daten validieren]
        Speichern[Bestellung speichern]
    end
    subgraph async [Hintergrundprozesse]
        Mail[Bestätigung versenden]
        Rechnung[Rechnung erzeugen]
    end
    UI --> Pruefen
    Pruefen --> Speichern
    Speichern --> Mail
    Speichern --> Rechnung

Im Editor öffnen

5. Eine Wiederholschleife mit begrenztem Ausstieg

Flussdiagramme kommen mit Zyklen gut zurecht, und bei einer Retry-Schleife zeigt sich ihr Wert: Das Diagramm macht sofort sichtbar, ob die Schleife überhaupt einen Ausgang hat.

flowchart TD
    Senden[Webhook senden] --> Ergebnis{2xx erhalten?}
    Ergebnis -->|ja| Quittung[Als zugestellt markieren]
    Ergebnis -->|nein| Zaehler{Versuch < 5?}
    Zaehler -->|ja| Warten[Exponentiell warten]
    Warten --> Senden
    Zaehler -->|nein| Tot[In Dead-Letter-Queue verschieben]

Im Editor öffnen

Syntaxreferenz für Flussdiagramme

Alles hier gilt nur für Flussdiagramme. Besonders die Pfeilformen lassen sich nicht auf andere Diagrammtypen übertragen — das `->>` eines Sequenzdiagramms ist hier ein Parse-Fehler.

Syntax	Bedeutung
flowchart TD	Von oben nach unten. Auch TB. Die übliche Leserichtung für einen Prozess.
flowchart LR	Von links nach rechts. Auch RL. Besser für breite, flache Abläufe.
A[Text]	Rechteck — ein gewöhnlicher Schritt.
A(Text)	Abgerundetes Rechteck.
A([Text])	Stadionform — üblicherweise Start oder Ende.
A[(Text)]	Zylinder — ein Datenspeicher.
A{Text}	Raute — eine Entscheidung.
A[/Text/]	Parallelogramm — Ein- oder Ausgabe.
A --> B	Pfeil.
A --- B	Linie ohne Pfeilspitze.
A -.-> B	Gepunkteter Pfeil — üblicherweise asynchron oder optional.
A ==> B	Dicker Pfeil — üblicherweise der Hauptpfad.
A -->\|Text\| B	Beschriftete Kante. Bei Klammern im Text in Anführungszeichen setzen.
A["Text (mit Klammern)"]	Zitierte Beschriftung — nötig für Klammern, Anführungszeichen und alles, was der Parser als Form-Syntax lesen würde.
subgraph name [Titel] ... end	Knoten in einem beschrifteten Kasten gruppieren. `end` schließt ihn.
%% Kommentar	Kommentarzeile, wird nicht gezeichnet.

Sechs Fehler, die Flussdiagramme wirklich zerlegen

Jeder Fall wurde mit dem Renderer nachgestellt, den diese Seite verwendet (Mermaid 11.12.2). Füge die fehlerhafte Fassung in den Editor ein, und du bekommst genau die beschriebene Meldung; die korrigierte Fassung rendert. Der schnellste Weg, eine Mermaid-Fehlermeldung zu lesen, ist das Ende: dort steht nach „got" das Token, an dem der Parser gescheitert ist.

Was du siehst

Parse error, endet mit: got 'PS'

Warum

Eine öffnende runde Klammer in einer eckigen Beschriftung. Runde Klammern sind Form-Syntax — `A(Text)` ist ein abgerundeter Knoten —, also liest der Parser die Klammer als Beginn einer Form.

Lösung

Setz die gesamte Beschriftung in doppelte Anführungszeichen. Alles darin gilt als Text.

Fehlerhaft

flowchart TD
    A[Erneut versuchen (max. 5)] --> B[Fertig]

Korrigiert

flowchart TD
    A["Erneut versuchen (max. 5)"] --> B[Fertig]

Was du siehst

Parse error, endet mit: got 'STR'

Warum

Ein doppeltes Anführungszeichen mitten in einer Beschriftung. Der Parser hält es für den Anfang einer Zeichenkette und trifft dann auf die schließende Klammer statt auf das zweite Anführungszeichen.

Lösung

Innen einfache Anführungszeichen verwenden, oder das Zeichen als `#quot;` schreiben.

Fehlerhaft

flowchart TD
    A[Status ist "offen"] --> B[Fertig]

Korrigiert

flowchart TD
    A["Status ist 'offen'"] --> B[Fertig]

Was du siehst

Parse error, endet mit: got 'end'

Warum

`end` als Knoten-ID. Kleingeschrieben schließt `end` einen Subgraph, der Parser sieht also einen Blockabschluss, wo ein Knoten stehen müsste. Das passiert oft, weil „end" der naheliegende Name für den letzten Knoten ist.

Lösung

Großschreiben oder dem Knoten eine ID geben und das Wort in die Beschriftung setzen.

Fehlerhaft

flowchart TD
    Start[Beginn] --> end

Korrigiert

flowchart TD
    Start[Beginn] --> Ende[Abgeschlossen]

Was du siehst

Parse error in der Zeile, in der du einen Knoten benannt hast

Warum

Ein Leerzeichen in der Knoten-ID. Die ID ist das Token vor dem Pfeil; ein Leerzeichen beendet es, und der Parser bleibt mit einem zweiten Wort zurück, das er nicht einordnen kann.

Lösung

Eine ID aus einem Wort verwenden und den lesbaren Text in die Beschriftung schreiben.

Fehlerhaft

flowchart TD
    offene posten --> mahnlauf

Korrigiert

flowchart TD
    posten[Offene Posten] --> mahnung[(Mahnlauf)]

Was du siehst

Parse error an einer Kantenbeschriftung zwischen senkrechten Strichen

Warum

Klammern in einer Kantenbeschriftung. Für `|…|` gilt dieselbe Einschränkung wie für Knotenbeschriftungen: Klammern sind dort Syntax, nicht Text.

Lösung

Auch die Kantenbeschriftung in Anführungszeichen setzen.

Fehlerhaft

flowchart TD
    A -->|nur einmal (sonst Abbruch)| B

Korrigiert

flowchart TD
    A -->|"nur einmal (sonst Abbruch)"| B

Was du siehst

Lexical error on line 1. Unrecognized text.

Warum

Eine ungültige Richtungsangabe. Flussdiagramme akzeptieren TB, TD, BT, LR und RL — sonst nichts. Eine unbekannte Angabe scheitert schon im Lexer, bevor irgendein Knoten gelesen wird. Deshalb zeigt der Fehler auf Zeile 1 statt auf deinen Tippfehler.

Lösung

Eine der fünf verwenden. TD und LR decken fast alles ab.

Fehlerhaft

flowchart OBENUNTEN
    A --> B

Korrigiert

flowchart TD
    A --> B

Hinweise zum Rendern

Gemessen an Mermaid 11.12.2, so wie diese Seite es einsetzt — nicht aus der Dokumentation übernommen. Das sind die Eigenheiten, die zählen, sobald ein Flussdiagramm kein Spielzeug mehr ist.

Die Höhe wächst um rund 105 px pro Knoten, die Breite kaum

Ein Flussdiagramm von oben nach unten mit 3 Knoten ergibt eine viewBox von etwa 122×382. Bei 40 Knoten sind es 131×4230 — die Breite ist um neun Pixel gewachsen, die Höhe um das Elffache. Lange Flussdiagramme werden zu schmalen Bändern, die auf keinen Bildschirm mehr passen; dafür gibt es die Zentrieren-Schaltfläche in der Vorschau. Wenn dir ein Diagramm vertikal davonläuft, kostet der Wechsel auf `flowchart LR` ein Wort und halbiert oft das Seitenverhältnis.

Beschriftungen sind HTML, und das hat den PNG-Export lange kaputt gemacht

Beschriftungen in Flussdiagrammen stecken in einem SVG-`<foreignObject>` mit echtem HTML darin. Deshalb funktionieren `<br>` und einfaches Markdown in einer Beschriftung. Es bedeutet aber auch, dass der Browser sich weigert, das SVG auf ein Canvas zu zeichnen — weshalb der PNG-Export auf dieser Seite lange stillschweigend eine SVG-Datei zurückgegeben hat. Der Export rendert das Diagramm inzwischen mit reinen SVG-Textbeschriftungen neu, sodass PNG funktioniert; der Preis ist eine minimal andere Typografie im PNG als am Bildschirm.

Das Theme ändert Farben, niemals das Layout

Dasselbe Flussdiagramm mit hellem und dunklem Theme ergibt eine identische viewBox. Ein Themewechsel kann ein Diagramm also nicht umbrechen oder eine Beschriftung aus ihrem Kasten schieben. Sieht etwas im Dunkelmodus falsch aus, ist es im Hellmodus genauso falsch.

Die Exportgröße kommt aus der viewBox, nicht vom Bildschirm

Mermaid gibt `width="100%"` und keine Höhe aus, die Bildschirmgröße hängt also vom Container ab. Der Export liest stattdessen die viewBox und rendert mit dem Zwei- bis Dreifachen davon. Deshalb ist das PNG eines langen Flussdiagramms deutlich größer als das, was du gerade angesehen hast. Die Zoomstufe hat auf den Export keinen Einfluss.

Nur kleingeschriebenes `end` ist reserviert

`End`, `ENDE` und `Endpunkt` sind ganz normale Knoten-IDs. Das ist nützlich zu wissen, weil der naheliegende Ausweg — den Knoten umbenennen — meist gar nicht nötig ist: ein Großbuchstabe reicht.

Wann etwas anderes besser passt

Geht es im Diagramm vor allem darum, wer was an wen schickt, und ist die zeitliche Reihenfolge wichtiger als die Verzweigung, wird ein Sequenzdiagramm klarer sein — und klar bleiben, wenn es wächst. Ein Flussdiagramm, in dem sechs Beteiligte als Knotennamen auftauchen, ist ein Sequenzdiagramm, das es noch nicht zugegeben hat.

Beschreibst du die Zustände, in denen ein Objekt sein kann, statt der Schritte eines Prozesses, nimm ein Zustandsdiagramm. Die Probe ist einfach: Sind deine Knotenbeschriftungen Substantive mit Eigenschaft („Bestellung offen", „Bestellung versendet"), ist es eine Zustandsmaschine; sind es Verben („Daten prüfen", „E-Mail senden"), ist es ein Flussdiagramm.

Und ab etwa vierzig Knoten hilft ehrlicherweise kein Diagrammtyp mehr. Teile es in mehrere Diagramme mit einem gemeinsamen Einstieg auf — oder akzeptiere, dass das, was du beschreibst, zu komplex für ein einziges Bild ist. Auch das ist eine brauchbare Erkenntnis.

Andere Diagrammtypen

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

Editor öffnen →