{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Participants{{ resultsReady ? computation.values.participant_count : '—' }} Notes{{ resultsReady ? computation.values.note_count : '—' }} Regions{{ resultsReady ? computation.values.control_region_count : '—' }}

Sequence orientation unavailable.

Declare participants first, then messages, notes, activations, and control regions. Limits: 12 participants, 60 messages, 40 notes, 20 regions, and 20,000 characters.
{{ fileStatus }}
Neutral when blank. The fallback title is “Sequence diagram”.

The traffic chart is unavailable. The same messages remain available in the sequence diagram and interaction ledger.

OrderEventParticipantsDetailCopy
{{ row.order }}{{ row.kind }}{{ row.participants }}{{ row.detail }}
Flowchart Generator Turn a reviewed text definition into a validated SVG flowchart, with reachability checks for every start-to-end process path.
SVG Placeholder Generator Create an SVG placeholder with exact pixel dimensions and readable labels, then copy accessible markup or CSS with contrast warnings for layout work.
Incident Timeline Report Turn incident notes into a sorted chronology with phase coverage, evidence gaps and response-cadence checks for a review-ready handoff report.
Application Programming Interface (API) Testing Tool Test HTTP APIs from your browser with cURL import and authentication while inspecting exposed headers, timing, response text and CORS failures.

Many technical discussions become difficult to follow when the order of events is left in prose. A sequence diagram puts participants across the page and time down the page, so a request, response, retry, or handoff can be read in the order it is meant to happen. It is especially useful for API calls, authentication flows, background jobs, incident timelines, and any review where timing between systems matters more than internal code structure.

The vertical lines are lifelines. Messages cross between them, activation bars mark periods of focused work, and control regions show loops or branches such as an accepted and rejected outcome. Notes can preserve a condition or review point without pretending it is another message.

Participant
A person, service, database, queue, or other named party in the interaction.
Message
A directed interaction whose vertical position records its order relative to other messages.
Control region
A labelled loop, alternative, optional path, parallel branch, critical section, or break in the normal flow.

A diagram is only as trustworthy as its source. It can clarify an intended design or reconstruct a reviewed incident, but it does not prove that a production system sends those messages, waits for those responses, or handles every failure shown. Compare important flows with logs, traces, tests, or the relevant interface contract.

Sequence syntax also varies among diagram systems. A small, explicit grammar is easier to validate and share safely, while a full diagram language may offer more styling and constructs. Moving source between them requires a compatibility check rather than assuming every statement has the same meaning.

How to Use This Tool:

Start with the parties in the interaction, then write events in the order a reviewer should read them.

  1. Begin Sequence definition with sequenceDiagram. Declare every participant or actor before the first message.
  2. Add messages one per line with a declared sender, an arrow, a declared receiver, and text after a colon. Add autonumber before the first event when numbered messages will make review easier.
  3. Add notes, activations, and labelled control regions only where they change the meaning of the interaction. Close every region with end and pair every activate with a later deactivate.
  4. Use Artifact title when the exported diagram needs a specific accessible title. A blank title becomes “Sequence diagram” without changing the interaction.
  5. Correct the first line-level error before reviewing the SVG. Then compare the participant-pair traffic and interaction ledger with the intended call order.

Interpreting Results:

Read the SVG from top to bottom. Horizontal position identifies the sender and receiver; vertical position identifies event order. A dashed or solid line and its endpoint communicate the chosen message style, but they do not add transport guarantees that are absent from the source.

  • Use message counts to find busy participant pairs, not to infer latency, throughput, or importance.
  • Check every alternative and parallel branch against the ledger so a visually compact region does not hide a missing event.
  • Treat a successful render as proof that the bounded grammar is valid, not that the architecture is complete or operationally correct.

Technical Details:

The source is parsed as inert text into participants and an ordered event list. Rendering begins only after declarations, references, activation pairs, control-region nesting, labels, and document limits pass validation. Labels are treated as text rather than executable markup.

Transformation Core:

StageTransformationAudit result
Line normalizationWindows and classic Mac line endings become line feeds; blank lines and lines beginning with %% are ignored.A stable source order for parsing.
Declaration passActors and participants are recorded before any event.Every later sender, receiver, note target, and activation target can be checked.
Event passMessages, notes, activation changes, region starts, branches, and ends become typed ordered records.Counts and the interaction ledger derive from one event order.
LayoutParticipant columns, lifelines, message rows, notes, activations, and control regions receive bounded SVG coordinates.An accessible inert SVG with a title and description.

Rule Core:

The accepted syntax is a deliberate subset rather than full Mermaid or PlantUML. The following rules determine whether a definition can render.

ConstructAccepted formImportant rule
HeadersequenceDiagramMust be the first material line.
Partyparticipant ID or actor ID as LabelDeclare at least two and no more than 12 before events.
MessageA->>B: Text and the supported solid, dashed, cross, or open-arrow variantsBoth IDs must already exist; 1 to 60 messages are required.
NoteNote over A,B: Text, Note left of A: Text, or Note right of A: TextSide notes name one party; at most 40 notes are accepted.
Activationactivate A followed later by deactivate ANested activation of the same party and unmatched deactivation are rejected.
Regionloop, alt, opt, par, critical, or break plus a labelUse else inside alt, and inside par, and option inside critical; close with end.

Control regions may nest six levels deep, with at most 20 regions. Participant labels are limited to 48 characters, message labels to 100, note text to 120, control labels to 80, the optional artifact title to 80, and the complete source to 20,000 characters.

Participant, message, note, and region counts are direct counts of validated records. They are not estimates and do not model elapsed time, concurrency, retries that were not written, or runtime traffic volume.

FAQ:

Can I paste any Mermaid sequence diagram?

No. The grammar supports the participant, message, note, activation, numbering, and control-region forms listed above. Styling directives, links, full Mermaid configuration, and other constructs should be removed or rewritten before rendering.

Is the sequence source executed or uploaded?

No. It is parsed as inert text and rendered in the browser. The page does not send the definition to a remote rendering service or execute content embedded in labels.

References: