Actors and participants
Separate people, applications, services, data stores, and external systems with explicit lifelines.
Interactions over time
Create a Mermaid sequence diagram online to document messages between users, services, APIs, and databases. Preview the interaction and export SVG or PNG.
Edit a request flow with participants, synchronous calls, a response, and an alternative branch while the rendered interaction stays visible.
Build a Mermaid sequence diagram online
Changes render automatically in the preview.
Sequence diagrams keep participants and messages aligned on a shared timeline so reviewers can see ownership, dependencies, and failure paths.
Separate people, applications, services, data stores, and external systems with explicit lifelines.
Use alt, opt, loop, and par blocks to document conditions, repetition, and concurrent work.
See the rendered diagram update after each source change and keep syntax errors beside the editor.
Download scalable SVG for documentation or a high-resolution PNG for slides and sharing.
Work in the browser without installing Mermaid CLI, a desktop application, or an editor extension.
Move the current source into the full editor for AI generation, repair, sharing, and saved projects.
Define the participants first, then record only the messages needed to explain one scenario from start to finish.
List the people and systems involved, using actor for a human role and participant for applications, services, or data stores.
Order participants so the most important request path reads naturally from left to right.
Add messages from top to bottom and label them with actions, commands, events, or meaningful response results.
Use alt, opt, loop, or par blocks only where the condition or repetition changes how readers understand the interaction.
Check the success and failure paths, then export the diagram or continue in the full editor.
A sequence diagram is most useful when it explains one scenario at a useful level of detail. Split unrelated workflows instead of forcing every system interaction into one timeline.
Use aliases when a technical identifier is useful in source but readers need a clearer display name. Keep each lifeline at one consistent abstraction level.
actor Customer
participant API as Orders API
participant DB as Order StoreSolid arrows work well for requests and commands, while dashed arrows make responses visually distinct. Message labels should state what crosses the boundary rather than repeat the participant name.
Customer->>API: Create order
API-->>Customer: Order IDUse an alt block for mutually exclusive outcomes and opt for an optional interaction. Name the condition in business terms so the diagram remains useful outside the implementation.
alt Payment approved
API-->>Customer: Confirmation
else Payment declined
API-->>Customer: Retry instructions
endUse a sequence diagram for ordered communication between participants. Use a flowchart for a process whose decisions and alternative paths matter more than which system sends each message.
The editable example follows a request from a user through a web application, API, and database, then separates the accepted and validation-failure outcomes.
sequenceDiagram
actor User
participant Web as Web App
participant API
participant DB as Database
User->>Web: Submit request
Web->>API: POST /requests
API->>DB: Store request
DB-->>API: Request ID
alt Request accepted
API-->>Web: 201 Created
Web-->>User: Show confirmation
else Validation failed
API-->>Web: 400 Validation error
Web-->>User: Show corrections
endContinue with the general editor, browse this release’s tool directory, or compare the diagram with a related modeling view.
Write Mermaid source, preview the result, and export SVG or PNG.
Open tool →Choose a focused Mermaid editor for the diagram you need to create.
Open tool →Create process flows, decisions, and system workflows from Mermaid text.
Open tool →It is a browser tool for writing Mermaid sequenceDiagram syntax, previewing participant interactions, and exporting the result as SVG or PNG.
Both create lifelines. Actor renders as a human-style actor and is useful for people or external roles, while participant is commonly used for applications, services, and data stores.
Use an alt block with an else branch. Put the outcome condition after alt and keep each branch focused on the messages that differ.
Yes. Wrap repeated messages in a loop block and label the loop with the condition or range that controls repetition.
Yes. SVG stays sharp at any scale, while PNG is convenient for presentations and systems that accept image attachments.
Include enough detail to answer one interaction question for one audience. Split the diagram when unrelated scenarios, low-level implementation calls, or too many participants obscure the main path.