Gratis · Geen registratie · Werkt met .mmd-bestanden

Mermaid sequentiediagram-editor

Een sequentiediagram laat zien wie met wie praat en in welke volgorde. Het past wanneer de uitwisseling van berichten tussen meerdere partijen het onderwerp is — authenticatie, betalen, koppelingen tussen diensten. Is er maar één deelnemer en gaat het om de vertakkingen, dan zegt een stroomdiagram hetzelfde met minder ruis.

Een iDEAL-betaling met terugkoppeling

De waarde van dit diagram zit in het `alt`-blok: het laat zien dat de betaling twee verschillende afloopen heeft en dat de webshop het resultaat niet van de klant hoort maar van de betaaldienst. Let ook op de laatste pijl: de bevestiging komt asynchroon terug, los van de browser van de klant. Precies dat maakt een sequentiediagram zichtbaar en verstopt een stroomdiagram.

sequenceDiagram
    autonumber
    participant K as Klant
    participant W as Webshop
    participant P as Betaaldienst
    participant B as Bank van de klant

    K->>W: Bevestig de bestelling
    W->>P: Start de transactie
    P-->>W: Betaal-URL
    W-->>K: Stuur door naar de bank
    K->>B: Kies rekening en bevestig

    alt Betaling geslaagd
        B-->>P: Geslaagd
        P-->>W: Statusmelding
        W->>W: Markeer als betaald
    else Geannuleerd of verlopen
        B-->>P: Geannuleerd
        P-->>W: Statusmelding
        W->>W: Houd de bestelling open
    end

    W-->>K: Toon de bevestigingspagina
Open dit in de editor
Advertentie

Uitgewerkte voorbeelden

1. Twee deelnemers en één bericht

`->>` is de pijl met gevulde punt, oftewel een aanroep. `-->>` is gestippeld en betekent het antwoord. Dat paar volstaat in de meeste diagrammen.

sequenceDiagram
    Client->>API: Maak de bestelling
    API-->>Client: 201 Created
In de editor openen

2. Aliassen voor lange namen

`participant X as Lange naam` geeft een korte id om te typen en een leesbare naam om te lezen. Deelnemers vooraan declareren legt ook hun volgorde in de tekening vast; zonder declaratie bepaalt de eerste vermelding die.

sequenceDiagram
    participant B as Browser
    participant O as Besteldienst
    participant V as Voorraaddienst

    B->>O: POST /bestellingen
    O->>V: Reserveer de artikelen
    V-->>O: Reservering bevestigd
    O-->>B: 201 Created
In de editor openen

3. Activaties en aanroepen naar zichzelf

`activate` en `deactivate` tekenen een balk die laat zien dat een deelnemer bezig is. De achtervoegsels `+` en `-` op de pijl doen hetzelfde met minder typewerk. Een pijl van een deelnemer naar zichzelf betekent intern werk.

sequenceDiagram
    participant A as API
    participant D as Database

    Client->>+A: GET /factuur/42
    A->>+D: SELECT factuur
    D-->>-A: Rij gevonden
    A->>A: Bereken de btw
    A-->>-Client: 200 OK
In de editor openen

4. Alternatieven, opties en lussen

`alt`/`else` zijn elkaar uitsluitende paden, `opt` is een blok dat er niet hoeft te zijn en `loop` is een herhaling. Alle drie sluiten af met `end`, en dat vergeten is de meestgemaakte fout van dit type.

sequenceDiagram
    participant G as Gebruiker
    participant A as API
    participant M as Maildienst

    G->>A: Vraag een account aan
    alt Adres al geregistreerd
        A-->>G: 409 Conflict
    else Adres nog vrij
        A-->>G: 201 Created
        A->>M: Stuur de verificatie
        loop Maximaal 3 pogingen
            M->>M: Herhaal bij mislukte verzending
        end
    end
    opt Gebruiker wil de nieuwsbrief
        A->>M: Voeg toe aan de lijst
    end
In de editor openen

5. Notities en gelijktijdige verwerking

`par` toont takken die tegelijk lopen, iets wat een stroomdiagram hooguit kan suggereren maar nooit uitspreekt. Notities zijn de juiste plek voor het detail dat niet in een berichtlabel past.

sequenceDiagram
    participant O as Besteldienst
    participant F as Facturatie
    participant L as Logistiek

    Note over O: De bestelling is al betaald

    par Meld het aan facturatie
        O->>F: Maak de factuur
        F-->>O: Factuur 2026/0431
    and Meld het aan logistiek
        O->>L: Bereid de zending voor
        L-->>O: Vrachtbrief aangemaakt
    end

    Note over F,L: Elk gaat in zijn eigen tempo verder
In de editor openen

Overzicht van de sequentiediagram-syntaxis

Wat je moet onthouden zijn de pijlen, en die horen uitsluitend bij dit type: de `-->` uit het stroomdiagram betekent hier iets anders, en de `->>` van hier is een fout in het klassendiagram.

SyntaxisBetekenis
sequenceDiagramOpent het diagram. Hoofdlettergevoelig: `sequencediagram` werkt niet.
participant ADeclareert een deelnemer en legt zijn positie vast.
participant A as NaamKorte id met leesbare naam.
actor AAls participant, maar tekent een poppetje.
A->>B: tekstBericht met gevulde punt — een aanroep.
A-->>B: tekstStippellijn — een antwoord.
A-)B: tekstOpen punt — asynchroon bericht.
A->>A: tekstDeelnemer roept zichzelf aan.
activate A / deactivate AMarkeert de periode waarin A bezig is.
A->>+B: / B-->>-A:Hetzelfde in korte vorm, direct op de pijl.
alt voorwaarde ... else ... endElkaar uitsluitende paden.
opt voorwaarde ... endBlok dat er niet hoeft te zijn.
loop tekst ... endHerhaling.
par ... and ... endGelijktijdige takken.
Note over A,B: tekstNotitie boven één of meer deelnemers. `Note left of` en `Note right of` bestaan ook.
autonumberNummert de berichten automatisch.
Advertentie

De zes fouten die een sequentiediagram slopen

Nagemaakt op Mermaid 11.12.2. De eerste is veruit de meest voorkomende, en de melding erbij hoort tot de slechtste aanwijzingen waar het probleem zit.

Wat je ziet

Parse error die naar de laatste regel van het diagram wijst

Waarom

Een blok dat geopend is en nooit gesloten. `alt`, `opt`, `loop` en `par` willen elk hun eigen `end`. Mermaid meldt de fout waar de invoer op is, dus het regelnummer wijst naar het einde van het bestand en niet naar het openstaande blok. Bij twee geneste blokken wordt dat echt lastig te vinden.

Oplossing

Tel de geopende blokken en de `end`s die je geschreven hebt. Wijst de fout naar de laatste regel, dan is dit het bijna altijd.

Fout
sequenceDiagram
    Client->>API: Verzoek
    alt Alles in orde
        API-->>Client: 200 OK
Goed
sequenceDiagram
    Client->>API: Verzoek
    alt Alles in orde
        API-->>Client: 200 OK
    end

Wat je ziet

No diagram type detected matching given configuration

Waarom

Verkeerde hoofdletters in het sleutelwoord. `sequenceDiagram` werkt; `sequencediagram` en `SequenceDiagram` niet. Mermaid is hoofdlettergevoelig in al zijn sleutelwoorden.

Oplossing

Hoofdletter D, de rest klein.

Fout
sequencediagram
    Client->>API: Hallo
Goed
sequenceDiagram
    Client->>API: Hallo

Wat je ziet

Het tekent, maar het bericht komt zonder label uit

Waarom

Er ontbreekt tekst na de dubbele punt. Gemeten: Mermaid weigert het niet — het tekent het bericht met een leeg label, en de pijl blijft zonder uitleg staan. Wat wél faalt is de dubbele punt helemaal weglaten: `Client->>API` alleen geeft `Expecting 'TXT', got 'NEWLINE'`. De dubbele punt is dus verplicht en de tekst niet, precies andersom dan je zou aannemen.

Oplossing

Schrijf iets na de dubbele punt, al is het één woord. Een pijl zonder label is bijna nooit wat je bedoelde.

Fout
sequenceDiagram
    Client->>API:
    API-->>Client: 200
Goed
sequenceDiagram
    Client->>API: Maak de bestelling
    API-->>Client: 200

Wat je ziet

Parse error na een `alt` met een lange voorwaarde

Waarom

Een regelafbreking binnen de voorwaarde van een blok. De voorwaarde van `alt`, `opt` of `loop` moet op één regel passen; breek je hem af, dan wordt de tweede helft als bericht gelezen en past nergens.

Oplossing

Houd de voorwaarde op één regel. Is hij te lang, kort hem in en verplaats het detail naar een notitie.

Fout
sequenceDiagram
    alt De klant heeft voldoende
    saldo op de rekening
        A-->>B: OK
    end
Goed
sequenceDiagram
    alt De klant heeft voldoende saldo
        A-->>B: OK
    end
    Note over A,B: Saldo wordt getoetst aan de daglimiet

Wat je ziet

Het tekent, maar er verschijnt een deelnemer die je niet gedeclareerd hebt

Waarom

Een tikfout in een deelnemersnaam. Mermaid maakt de deelnemer aan zodra hij een naam voor het eerst tegenkomt, dus `Betaaldienst` en `Betaaldiensr` zijn twee losse kolommen en niets waarschuwt je. In het Nederlands is de lange samenstelling de meest voorkomende bron: hoe langer het woord, hoe makkelijker er één letter in verschuift.

Oplossing

Declareer de deelnemers vooraan met `participant`. Dat voorkomt de tikfout niet, maar maakt zichtbaar welke namen de juiste zijn, en de kolom te veel valt meteen op.

Fout
sequenceDiagram
    Webshop->>Betaaldienst: Start de transactie
    Betaaldiensr-->>Webshop: Statusmelding
Goed
sequenceDiagram
    participant W as Webshop
    participant P as Betaaldienst
    W->>P: Start de transactie
    P-->>W: Statusmelding

Wat je ziet

Het tekent, maar de kolomvolgorde is niet die je bedoelde

Waarom

Je hebt de deelnemers niet gedeclareerd. Zonder declaratie bepaalt de eerste vermelding van elke naam de volgorde, dus een bericht dat je bovenaan het diagram toevoegt kan alle kolommen herschikken en de pijlen over elkaar heen laten lopen. Het diagram blijft correct, maar leest een stuk slechter.

Oplossing

Declareer alle deelnemers in de kop, in de volgorde waarin je ze wilt zien.

Fout
sequenceDiagram
    Bank-->>Betaaldienst: Geslaagd
    Klant->>Webshop: Bevestig de bestelling
    Webshop->>Betaaldienst: Start de transactie
Goed
sequenceDiagram
    participant Klant
    participant Webshop
    participant Betaaldienst
    participant Bank
    Klant->>Webshop: Bevestig de bestelling
    Webshop->>Betaaldienst: Start de transactie
    Betaaldienst->>Bank: Stuur door
    Bank-->>Betaaldienst: Geslaagd

Aantekeningen over het tekenen

Gemeten op Mermaid 11.12.2, de versie die deze site gebruikt. Het sequentiediagram gedraagt zich op twee concrete punten anders dan de rest.

De breedte bepalen de deelnemers, niet de berichten

Gemeten: twee deelnemers geven een viewBox van 450 pixels breed, zes geven er 1250, dus ongeveer 200 pixels per extra kolom, ongeacht wat er in de berichten staat. Berichten voegen alleen hoogte toe, ongeveer 46 pixels per stuk. Met één voorbehoud: is een berichtlabel breder dan de minimale kolombreedte, dan verbreedt het het diagram wel degelijk — hetzelfde paar deelnemers ging van 450 naar 603 pixels puur doordat de tekst van één bericht langer werd. Nederlandse labels zijn de langste die hier gemeten zijn, dus dat gebeurt eerder dan in het Engels.

Het enige type met een negatieve viewBox-oorsprong

Sequentiediagrammen komen eruit met een viewBox die begint op `-50 -10` in plaats van `0 0`. Dat is geen defect: Mermaid reserveert die marge voor de kaders van de deelnemers. Het telt alleen als je de SVG met eigen gereedschap verwerkt, want elke berekening die van oorsprong nul uitgaat, kapt de eerste kolom af.

Hier klopt de PNG-export wel

Anders dan het stroomdiagram en de klassen-, toestands- en ER-diagrammen tekent het sequentiediagram zijn labels als gewone SVG-tekst en niet binnen een `<foreignObject>`. Daardoor laat het zich rechtstreeks rasteren: de geëxporteerde PNG komt overeen met het scherm, zonder tussentijdse hertekening en zonder verschuiving in de zetwijze.

Een gedeclareerde en ongebruikte deelnemer wordt toch getekend

Een `participant` die geen enkel bericht verstuurt of ontvangt, verschijnt in het diagram met een lege kolom. Soms is dat bedoeld, om iemand te tonen die bestaat maar niet aan deze stroom meedoet. Vaker is het het restant van een deelnemer wiens laatste bericht is weggehaald zonder de declaratie mee te verwijderen.

Het thema verandert de kleuren, nooit de geometrie

Hetzelfde diagram in het lichte en het donkere thema geeft een identieke viewBox, dus kolommen schuiven niet en blokken veranderen niet van formaat als het thema wisselt.

Wanneer een ander diagram beter past

Is er maar één deelnemer, dan valt er geen volgorde te tonen. Een diagram met één kolom en pijlen naar zichzelf is een stroomdiagram dat ongemakkelijk is opgeschreven.

Wil je de toestanden beschrijven die iets doorloopt en niet het gesprek tussen partijen, gebruik dan een toestandsdiagram. Het signaal is duidelijk: schrijf je keer op keer hetzelfde bericht met een andere voorwaarde, dan heb je een toestandsmachine voor je.

En loopt de uitwisseling boven de vijftien berichten, splits hem dan. Een sequentiediagram met zestig berichten is technisch correct en voor mensen onbruikbaar; het leest vrijwel altijd beter als drie diagrammen, één per fase, verbonden met een notitie.

Andere diagramtypen

Geschreven door Dominik Malsch · Laatst bijgewerkt:

Editor openen →