Type Mermaid syntax, get an entity relationship diagram — live
erDiagram on line one, entity blocks like CUSTOMER { int id PK }, then relationship lines such as CUSTOMER ||--o{ ORDER : places — exactly one customer places zero-or-more orders. This maker renders the MIT-licensed Mermaid 11 library locally in your browser and exports SVG or PNG.
| Syntax | What it draws |
|---|---|
erDiagram | Required first line |
CUSTOMER { ... } | Entity block (attribute rows go inside) |
int id PK | Attribute row: type, name, key marker |
int customer_id FK | Foreign key badge |
string email UK | Unique / alternate key badge |
string note "free text" | Quoted comment on an attribute |
A ||--|| B : has | One-to-one |
A ||--o{ B : contains | One-to-zero-or-more |
A |{--|{ B : requires | One-or-more to one-or-more |
A o|--o| B : maybe | Zero-or-one to zero-or-one |
A }o--o{ B : links | Many-to-many (both sides crow's feet) |
Read the cardinality symbols in pairs: || exactly one, o| zero-or-one, |{ one-or-more, o{ zero-or-more. The left pair describes the left entity's count of the right one, and the right pair the reverse. Types before names are free-form — write whatever your database actually uses.
An entity relationship diagram is the map of stored data: which tables exist, which columns identify rows, and how many of each side a connection allows. It earns its keep at design time — before the first migration — and later as the picture new engineers orient by. Because it describes structure rather than behavior, it pairs naturally with a class diagram for the code that reads and writes these tables.
Edit on the left; the preview re-renders about 400 ms after you pause, with parse errors shown under the editor. Export SVG for wikis and design docs, PNG for slides. Everything runs locally in your browser.
The default diagram is a small storefront schema. Count it out: 5 entities, 4 relationships, 4 primary keys. The chain CUSTOMER ||--o{ ORDER ||--|{ LINE_ITEM }o--|| PRODUCT is the classic order spine — one customer places many orders, each order contains one-or-more line items, and each line item points back to exactly one product. LINE_ITEM carries a composite identity: both order_id and product_id are FK, which is how a join table with attributes is usually modeled.
erDiagram — the type declarationCUSTOMER ||--o{ ORDER : places — crow's-foot one-to-manystring email UK — unique key badge on the attribute rowPRODUCT ||--o{ CATEGORY : "sorted into" — labels can carry spaces when quotedRenaming a column or flipping a cardinality is a one-line edit followed by an automatic redraw, which is why text-based ERDs stay closer to the real schema than hand-drawn ones ever do.
Start the first line with erDiagram, define each entity as a block listing its attributes with key markers (int id PK, string email UK), then connect entities with relationship lines like CUSTOMER ||--o{ ORDER : places. This maker renders live in your browser with crow's-foot notation and exports SVG or PNG — free, no signup, nothing uploaded.
It is crow's-foot cardinality read left to right: || means exactly one, o{ means zero-or-more. So CUSTOMER ||--o{ ORDER : places says each customer places zero or more orders, and each order belongs to exactly one customer. Other endings: |{ one-or-more, || exactly one, o| zero-or-one. The two halves sit on either side of the double dash, one for each direction.
Put the key marker after the attribute name inside the entity block: int id PK for primary key, int customer_id FK for foreign key, string email UK for a unique (alternate) key. Mermaid renders the marker as a small badge on that attribute row. Composite keys list PK on two lines.
The type is free-form text before the attribute name — string, int, float, bool, date, or anything your stack calls it (varchar(255), uuid, decimal(10,2) all render fine). Mermaid does not validate types; it prints them exactly as written, so use the names your actual database uses to keep the diagram honest.
An ER diagram models persisted data: tables or entities, their attributes, and the cardinality of the links between them. A class diagram models code: classes with behavior (methods) and object relationships like inheritance. Overlap exists — a Customer appears in both — but methods belong to class diagrams and PK/FK badges belong to ER diagrams.