Beauty Diagram
Diagram type

Mermaid Class Diagram Syntax & Examples

Reference for Mermaid class diagram syntax — class declarations, fields, methods, visibility modifiers, inheritance, composition, and multiplicity. Copy-paste examples.

Syntax reference, layout guidance, and ready-to-open examples for this diagram type.

At a glance

A syntax reference for Mermaid's classDiagram grammar — read this when you need the exact notation for a relationship arrow, visibility modifier, or annotation, then try the result in the editor.

What is a Mermaid class diagramDeclaring a class — fields & methodsRelationships — inheritance, composition, associationMultiplicity — one-to-many, many-to-manyAnnotations & stereotypesCommon patterns & gotchas
Syntax reference

Mermaid class diagram constructs, one per row

ConstructSyntaxNotes
Diagram keywordclassDiagramMust be the first line, on its own.
Class with membersclass Animal { +String name }Members go inside the braces, one per line. A class can also be declared bare as class Animal.
Visibility+ public - private # protected ~ packageThe prefix character is stripped from the label and drives the rendered marker.
Method+isMammal() boolParentheses are what distinguish a method from a field; the trailing word is the return type.
Annotation<<interface>>Written on its own line inside the braces. <<abstract>>, <<enum>> and any custom stereotype work the same way.
Genericsclass Box~T~Tildes stand in for angle brackets, which would otherwise be read as markup.
Inheritance / realizationAnimal <|-- DuckSolid is inheritance; the dotted forms <|.. and ..|> are realization. Reversing the arrow (Duck --|> Animal) points it the other way.
Composition / aggregationProduct *-- LineItem*-- is composition (filled diamond), o-- is aggregation (hollow diamond).
Dependency / associationSource ..> TargetDotted is a dependency; the solid --> is a plain association.
Cardinality and labelOwner "1" --> "*" Dog : ownsQuoted multiplicities sit next to each end. "1", "*", "0..1", "1..*" and ranges like "2..4" all render.

Syntax reviewed

Rendered proof
Minimal Mermaid class diagram with inheritance and composition.
Theme · Atelier
Open this diagram in editor
CLASS HIERARCHY owns 1 * Animal +String name +int age +makeSound() void Dog +String breed +bark() void Owner +String name
View Mermaid sourcePlain-text diagram syntax — copy or edit directly.
diagram.mmd
1classDiagram
2  class Animal {
3    +String name
4    +int age
5    +makeSound() void
6  }
7  class Dog {
8    +String breed
9    +bark() void
10  }
11  class Owner {
12    +String name
13  }
14  Animal <|-- Dog
15  Owner "1" --> "*" Dog : owns

What is a Mermaid class diagram

A Mermaid class diagram captures types, their fields and methods, and the relationships between them — the standard UML class-diagram view in a text-based form. It is the right shape when the question is what-are-the-types-and-how-do-they-relate: domain model reviews, module boundaries, API contract walkthroughs, onboarding documentation that introduces a codebase. If the question is what-order-do-things-happen-in, use a sequence diagram instead; if it is what-states-can-an-entity-be-in, use a state diagram. Class diagrams describe structure, not behaviour or time.

Declaring a class — fields & methods

A class block starts with class Name { ... }. Inside, each line is a field (+name: type) or method (+method(arg: type) returnType). The leading symbol is a visibility modifier: + public, - private, # protected, ~ package-private. Field syntax accepts both name: type and the C-style type name forms. Methods always have parentheses, even when empty. Mermaid is lenient about whitespace inside the braces — you can write each member on its own line for readability or pack several into one line.

  • class Animal { +String name } — single field
  • +method(arg: type) returnType — public method with typed arg
  • Visibility modifiers: + public, - private, # protected, ~ package-private

Relationships — inheritance, composition, association

Mermaid supports the full UML relationship vocabulary. Animal <|-- Dog reads as Dog inherits from Animal (the arrowhead <| points at the parent). Composite *-- Part is composition (the diamond * is filled, meaning the part is owned by the composite and dies with it). Aggregate o-- Member is aggregation (open diamond, weaker ownership). Source --> Target is a directional association (a uses-a relationship). Source ..> Target is a dashed dependency (lighter coupling). Interface ..|> Implementation is realization (a class implements an interface). Each arrow direction encodes a specific semantic — the reader recognises the relationship type from the arrow alone before reading any label.

  • <|-- — inheritance (Class inherits from parent)
  • *-- — composition (owned, dies-with parent)
  • o-- — aggregation (referenced, lives independently)
  • --> — association (general uses-a)
  • ..> — dependency (loose coupling)
  • ..|> — realization (implements an interface)

Multiplicity — one-to-many, many-to-many

Multiplicity is expressed as quoted strings on the relationship line: Owner "1" --> "*" Dog. The two strings appear at each end of the line and tell readers the cardinality at that end. Common values: "1" exactly one, "0..1" zero or one, "*" zero or more, "1..*" one or more, or any specific range like "2..4". Labels can be added after the arrow with a colon: Owner "1" --> "*" Dog : owns. The combination of cardinality at both ends plus a verb label communicates the relationship completely.

Annotations & stereotypes

Mermaid supports class annotations using the <<...>> syntax: class Database { <<interface>> }. Common stereotypes include <<interface>>, <<abstract>>, <<enum>>, <<service>>, and custom ones. The annotation appears above the class name in the rendered diagram and helps readers categorise classes without inspecting their members. For enumerations specifically, you can list values directly inside the class block: class Status { <<enum>> PENDING APPROVED REJECTED }. These annotations are particularly valuable in larger diagrams where the role of each class is otherwise not obvious.

Common patterns & gotchas

Three patterns appear constantly. Domain models combine class blocks with inheritance and composition — Product *-- LineItem style. Service architectures use <<interface>> annotations with realization arrows. API contracts use abstract classes for the request/response base types. The most common gotcha: forgetting that Mermaid is case-sensitive on class names — class User { } and a later reference to user are two different classes. Second gotcha: methods without parentheses are parsed as fields, so +save void (without ()) becomes a field, not a method. Always include () on methods.

  • Class names are case-sensitive — User and user are different classes
  • Methods always need () — without parens they parse as fields
  • Whitespace inside class blocks is flexible; one member per line reads best
FAQ

Mermaid Class Diagram Syntax & Examples — frequently asked questions

How do I show inheritance in a Mermaid class diagram?

Use the <|-- arrow between the parent and the child: Animal <|-- Dog means Dog inherits from Animal. The arrowhead <| always points at the parent, regardless of which side of the line you write it on (Dog --|> Animal also works). Mermaid's UML convention here matches the standard — the closed triangular arrowhead is exclusively for inheritance.

What's the difference between composition (*--) and aggregation (o--)?

Composition (Composite *-- Part, filled diamond) means the part is owned by the composite and dies when the composite dies — strong ownership. Aggregation (Aggregate o-- Member, open diamond) means the aggregate has-a member but the member lives independently — weak ownership. Use composition for lifecycles tied together (Order has-LineItems that don't exist without the Order). Use aggregation for shared references (Team has-Players who exist outside any single team).

How do I write a visibility modifier on a field or method?

Prefix the field or method name with the modifier symbol: + public, - private, # protected, ~ package-private. For example, +name: String is a public field; -id: int is a private field; #calculate() is a protected method. The modifier appears in the rendered diagram as the corresponding UML symbol. If you omit the modifier, the field or method renders without visibility — which is fine for high-level diagrams but loses information for detailed design docs.

How do I express multiplicity in a relationship?

Wrap the cardinality in quotes at each end of the arrow: Owner "1" --> "*" Dog means one Owner has many Dogs. Common values: "1" exactly one, "0..1" optional, "*" zero or more, "1..*" one or more, or specific ranges like "2..4". Combine with a label: Owner "1" --> "*" Dog : owns. The cardinality at both ends plus a verb label communicates the full meaning of the relationship.

Can I show that a class is an interface or abstract?

Yes — use the <<stereotype>> annotation inside the class block: class Repository { <<interface>> }, class Vehicle { <<abstract>> }. Common stereotypes include <<interface>>, <<abstract>>, <<enum>>, and <<service>>. The annotation renders above the class name and tells readers the role at a glance. For enums you can also list values inside: class Status { <<enum>> PENDING APPROVED REJECTED }. Implementations of interfaces use the realization arrow: Repository <|.. UserRepository (note the dashed line for realization vs the solid line for inheritance).