Type Mermaid syntax, get a UML class diagram — live
class Vehicle { +String name +start() void } and connect with Vehicle <|-- Car for inheritance, *-- for composition, o-- for aggregation. Visibility markers (+ public, - private, # protected) prefix each member. This maker renders the MIT-licensed Mermaid 11 library in your browser and exports clean SVG or PNG.
| Syntax | What it draws |
|---|---|
classDiagram | Required first line |
class Order { ... } | Box with member compartments |
+String email | Public attribute (member syntax: visibility, name, optional type) |
-hashPassword(pwd) | Private method |
#rowCount() int | Protected method with return type |
<<interface>> | Stereotype label line inside the class body |
<<abstract>> / <<enumeration>> | Other common stereotypes |
A <|-- B | Inheritance — B extends A (triangle at A) |
A <|.. B | Realization — B implements interface A |
Whole *-- Part | Composition — part dies with whole |
Whole o-- Part | Aggregation — part can outlive whole |
A -- B / A --> B | Association / directed association |
A ..> B : uses | Dependency — A temporarily uses B |
A "1" --> "0..*" B | Multiplicity labels on the ends |
note for Order "text" | A note attached to one class |
The direction you write a relationship matters: in Vehicle <|-- Car the triangle points at Vehicle, the parent. Mermaid is picky about spaces inside braces — one member per line, no blank lines inside the block.
Class diagrams are the static view of an object-oriented design: what types exist, what they hold, what they can do, and how they relate. They don't show control flow (that's a sequence diagram) or stored data (that's an ER diagram). They're the diagram you sketch before writing the first class, and the one you keep beside the code as it grows.
The editor on the left renders about 400 ms after you stop typing; the status line flags parse errors. Export SVG for documentation or PNG for a slide. Both are produced locally — your code never leaves the browser.
The default diagram models a payment flow. Count before you draw: 6 classes, 5 relationships. PaymentMethod is an interface (the <<interface>> stereotype); CreditCard and BankAccount each realize it with <|.., which is why two dotted arrows point at the same box. Order *-- LineItem is composition — delete the order and its line items go with it. Customer "1" --> "0..*" Order says one customer can hold any number of orders, including none.
classDiagram — the type declarationPaymentMethod <|.. CreditCard — realizesOrder *-- LineItem — compositionCustomer "1" --> "0..*" Order : places — association with multiplicity and a labelSix classes and five arrows fit on one screen; the same drawing in a canvas tool is twenty drag operations and an alignment pass. That's the usual experience with diagrams-as-code — structure is cheap to revise, so you revise it more often.
Open a file with classDiagram, declare classes with class Name { ... }, list attributes and methods inside the braces (visibility marker first: + public, - private, # protected), then connect classes with relationship arrows like Vehicle <|-- Car for inheritance. This maker renders live in your browser and exports SVG — no account, no watermark.
They are UML visibility markers. + means public (any class can call it), - means private (only the class itself), and # means protected (the class and its subclasses). ~ marks package-private. You write them at the start of each member line, as in +String name or -balance() float, and Mermaid shows them as a gutter character next to each member.
Inheritance is ClassA <|-- ClassB (a hollow triangle pointing at the parent). Composition, where the part dies with the whole, is Whole *-- Part. Aggregation, where parts survive, is Whole o-- Part. Plain association is --, dependency (uses-temporarily) is ..>, and realization of an interface is <|.. Implementer. The shape at the parent end and the line style carry the meaning.
Put the multiplicity on the relationship line with quotes: Customer "1" --> "*" Order : places. Read it as one customer places zero-or-more orders. Common values are 1, 0..1, *, and 1..*, and you can put a label after a colon to name the relationship in plain English.
Yes. Inside the class body, write <<abstract>> or <<interface>> on its own line and Mermaid adds the UML stereotype label. <<enumeration>> works the same way for enums, where you then list the allowed values as members. Abstract classes render with an italic stereotype tag above the member list.