Mermaid Class Diagram Tutorial
Class diagrams model the structure of object-oriented code. Mermaid lets you write them in text and keep them next to the code they describe.
A class diagram is the backbone of object-oriented design documentation. It shows the classes in a system, what data and behavior each holds, and how they relate - which classes inherit from which, which contain others, which depend on others. Mermaid's class diagram syntax lets you express all of this in text that lives alongside your code, so the diagram can be reviewed in pull requests and updated as the code evolves rather than rotting in a forgotten design doc.
This tutorial covers the essentials: declaring classes with attributes and methods, showing visibility, and drawing the relationships that give a class diagram its meaning. Each concept comes with a short snippet you can paste into the live editor at /diagram-tools/mermaid-editor to see rendered. Class diagrams are one of the more structured Mermaid types, and getting the relationship syntax right is where most of the learning lies.
Declaring a class
A class diagram starts with `classDiagram` on its own line. You define a class and its members with a block: `class Animal` followed by a brace block containing attributes and methods. Inside, `+String name` declares a public attribute called name of type String, and `+eat()` declares a public method. The `+` is a visibility marker - public. You can also use `-` for private, `#` for protected, and `~` for package-level visibility, mirroring UML conventions.
A complete small class might read: `class Animal`, then inside the braces `+String name`, `+int age`, `+eat()`, `+sleep()`. Mermaid renders this as the familiar three-compartment UML box - the class name at top, attributes in the middle, methods at the bottom. You can also declare members with a shorthand outside the block using the colon syntax, like `Animal : +String name`, which some people find quicker for adding one member at a time.
Relationships between classes
Relationships are what turn a set of class boxes into a design. Mermaid draws each relationship type with a distinct line and arrowhead, and choosing the right one communicates real meaning about how classes connect. Here are the relationship types and their syntax.
- Inheritance: `Animal <|-- Dog` - Dog inherits from Animal, drawn with a hollow triangle arrowhead.
- Composition: `Car *-- Engine` - a strong whole-part relationship; the part cannot exist without the whole. Filled diamond.
- Aggregation: `Team o-- Player` - a weaker whole-part relationship; the part can exist independently. Hollow diamond.
- Association: `Driver --> Car` - a general relationship, one class uses or references another.
- Dependency: `Order ..> Product` - a dashed line showing one class depends on another loosely.
- Realization: `Shape <|.. Circle` - a class implements an interface, drawn with a dashed line and hollow triangle.
- Link labels and multiplicity refine any of these, described next.
Multiplicity and labels
Relationships often carry multiplicity - how many of one class relate to how many of another. Mermaid puts multiplicity in quotes at each end of the relationship: `Customer "1" --> "*" Order` reads as one customer relates to many orders. The common multiplicity markers are `1` for exactly one, `*` for many, `0..1` for zero or one, and `1..*` for one or more. Getting these right captures important constraints of the domain model.
You can also label a relationship to name it: `Customer "1" --> "*" Order : places` adds the verb "places" to the line, so it reads "one customer places many orders". These labels make a class diagram read almost like sentences describing the domain, which is exactly the clarity you want. The combination of the right relationship type, multiplicity, and a label turns a bare connection into a precise statement about how two classes relate.
Annotations and generics
Class diagrams sometimes need to mark a class as something special, like an interface or an abstract class. Mermaid uses annotations in double angle brackets for this: putting `<<interface>>` inside a class block marks it as an interface, and `<<abstract>>` marks an abstract class. These stereotypes appear above the class name in the rendered diagram, the standard UML way of indicating a class's special nature.
Mermaid also supports generics and static or abstract members. You express a generic type with a tilde, like `List~int~` for a list of integers. A static member is marked with a `$` and an abstract one with a `*` after the member. These details let a Mermaid class diagram capture the real structure of typed, object-oriented code faithfully. When a class diagram grows large or you want to arrange it precisely for a document, you can import the Mermaid into Atlas Diagram Studio and refine the layout visually on the canvas at /diagrams, keeping the option to switch back to text editing in the Mermaid editor at /diagram-tools/mermaid-editor.