Class Diagram

Last updated: May 25, 2026

Mermaid Studio adds full language support for UML class diagrams to JetBrains IDEs: smart completions, live templates, quick fixes and intentions, a structure view with package grouping, gutter navigation between related classes, inlay hints, and inline documentation. No other IDE plugin treats Mermaid class diagrams with this depth of language tooling. The sections below walk through each capability.

Feature spotlight

The sections below highlight the features that most change how you author class diagrams day-to-day.

Smart completions

Completion is wired into every meaningful position the parser tracks: class references, statement keywords, relationship operators, cardinality strings, click and link continuations, CSS property names, and CSS class names each surface where they are valid and stay quiet where they aren’t. The popup also includes the live templates from the next section, so scaffolding new declarations and filling in existing ones share one workflow.

Class references. Anywhere a class id is expected, completion suggests the classes already declared in the file: relationship endpoints (typing Order and triggering completion offers the classes that can sit on the right side), style / cssClass targets, click / link / callback targets, note for ..., and the first id of a new relationship at statement start. The forward-referenced-style inspection in Quick fixes and intentions catches references to a class declared later in the file.

Style classes and CSS properties. The ::: separator and the cssClass target slot complete from your classDef declarations. CSS property names complete inside classDef and style property lists.

Relationship operators. Operator completion offers every combination of arrowheads and line styles (inheritance, realization, composition, aggregation, association, dependency, and their bidirectional and asymmetric variants), each labelled with its UML kind so you don’t have to remember which arrow points which way. Partial-prefix typing (<|-, --, etc.) filters the popup live, and the operator is suppressed once the line already has one so it doesn’t hijack the next class-ref slot.

Relationship operator completion showing every bidirectional and asymmetric form

Cardinality presets. Cardinality slots offer presets like 1, 0..1, 1..*, *, n, 0..n, 1..n, many, and one or more. Free-form text remains accepted; the presets are a convenience layered on top of the upstream string grammar.

Cardinality completion presets inside a relationship's quoted cardinality slot

Click and link continuations. After typing click ClassName , completion offers the two valid sub-keywords (href for a URL and call for a JavaScript callback). After the URL of a click or link statement, completion offers the link-target keywords (_self / _blank / _parent / _top).

Live templates

A set of context-aware live templates scaffolds class declarations, namespaces, notes, and every relationship form. Type a short abbreviation, accept it from the completion popup, and tab through the template variables. Class-name completion fires automatically inside relationship endpoints, so a hierarchy never requires retyping a class id.

Individual abbreviations can be toggled under Settings > Tools > Mermaid Studio > Live Templates in the Class Diagram group. See Live Templates for the cross-cutting mechanics (triggering, contextual visibility, configuration).

Class declarations

Abbreviation	Expansion
`cls`	Class declaration
`clsa`	Abstract class declaration (`<<abstract>>`)
`clsi`	Interface declaration (`<<interface>>`)
`clsenum`	Enumeration class declaration (`<<enumeration>>`)
`clssvc`	Service class declaration (`<<service>>`)
`clsentity`	Entity class declaration (`<<entity>>`)
`clsrepo`	Repository class declaration (`<<repository>>`)
`clsctrl`	Controller class declaration (`<<controller>>`)
`clsutil`	Utility class declaration (`<<utility>>`)
`ns`	Namespace block

Notes

Abbreviation	Expansion
`nfc`	`note for Class "..."`

Relationships

Each relationship template uses class-name completion for both endpoints.

Abbreviation	Expansion
`relinh`	Inheritance (`Child --\|> Parent`)
`relreal`	Realization (`Class ..\|> Interface`)
`relcomp`	Composition (`Part --* Whole`)
`relagg`	Aggregation (`Part --o Whole`)
`relassoc`	Directed association (`From --> To`)
`reldep`	Dependency (`From ..> To`)
`rellol`	Lollipop interface (`Client --() Provider`)
`rellink`	Solid link, no arrows (`A -- B`)
`reldash`	Dashed link, no arrows (`A .. B`)

Visual editing

Class diagrams support visual editing. Click an element in the preview to select it; double-click to start editing it. Different elements use different edit surfaces:

Classes open in a popup dialog (rename, change annotation, other class-level edits).
Relationship labels, note bodies, and namespace titles edit inline in the preview.
All elements support visual property editing through the Style Pane.

Style pane

The Style Pane covers class diagrams as a first-class diagram type. Styleable elements are classes (with full color, typography, and shape control) and relationships (with arrowhead, line-style, and cardinality controls).

Class styling

Apply style presets or custom CSS properties to classes.

Relationship controls

When a relationship is selected, the Style Pane shows three controls.

Arrowhead pickers (left and right). Each end of the relationship has its own dropdown with visual previews of every option: inheritance (<\|), dependency (>), composition (*), aggregation (o), and lollipop (()). Picking a different arrowhead at either end updates the relationship operator in the source.

Solid / dashed line picker. Switch the line between solid (--) and dashed (..).

Cardinality (left and right). Type a cardinality directly or pick from common shorthands (1, 0..1, *, 1..*, n, 0..n, many, one or more). Each preset has a hover tooltip explaining what the shorthand means, so you don’t have to remember UML notation conventions to use it.

Class editor dialog

Double-click a class in the preview to open the Class editor dialog. The dialog covers class-level edits that previously meant typing directly in the source: rename, change the annotation (<<interface>>, <<abstract>>, <<enum>>, etc.), and other class-level fields.

Inline label editing

Three other class-diagram element kinds support double-click inline editing in the preview:

Relationship labels — the text after the : on a relationship line. Double-click the label in the preview to edit it in place; commit with Enter Enter or by clicking outside.
Notes — double-click a note body to edit its text inline. Works for both note for ClassName "..." and standalone note "..." declarations.
Namespace titles — double-click the title of a namespace { ... } block to edit it. The editor auto-wraps the new value in backticks when the content would otherwise corrupt the syntax (for example, multi-word titles or content containing punctuation that the inline editor would otherwise replace).

Quick fixes and intentions

Inspections flag class-diagram-specific issues as you type, and many ship with a one-keystroke fix.

Add class declaration — for any class that’s referenced but never declared (in a relationship, style/cssClass target, click/link/callback, or note), inserts a class declaration at the top of the diagram body.

Add class declaration intention bulb on an unresolved class reference

Merge class declarations — when a class is declared more than once across the file (e.g. once at top level and once inside a namespace { } block), consolidates every declaration into the one under the caret with all members preserved.

Merge declarations of Order here intention

Move styling statement to end of file — Mermaid’s runtime applies style and cssClass only to classes that have already been declared, so a forward reference silently drops the styling. The inspection flags the case and the quick fix moves the statement past every declaration so it takes effect.

Move styling statement to end of file quick fix on a forward-referenced style statement

Other inspections cover duplicate attributes / methods, empty namespaces, unresolved annotation classes, and more. See Settings > Editor > Inspections > Mermaid > Class Diagram for the full list and per-rule severity controls.

Structured members and generics

Upstream Mermaid renders class member lines as opaque text. The renderer reads () to decide whether a line is a method or an attribute, and the rest of the line passes through verbatim with no further structure. Generic content inside ~...~ is treated the same way. Mermaid Studio parses members into a structured PSI tree on top of that grammar. Visibility sigils, modifier suffixes, attribute and method names, parameter lists, return types, and generic parameters each become first-class elements that completion, navigation, refactoring, and highlighting can reason about.

What this gets you in practice:

Type-aware highlighting — see at a glance which type references in a member resolve to a class declared in the file versus a built-in, primitive, generic parameter, or unresolved name, so you can scan a class body and immediately tell what’s defined versus what’s just a reference. Every type identifier in a member position is classified as: a declared class (clickable), a generic parameter, a primitive (int, bool, char), a built-in (String, Object, Optional, Pair), a collection (List, Map, Set, Array), or an unresolved class reference. Each category has its own color-scheme attribute under Settings > Editor > Color Scheme > Mermaid Class Diagram.
Generic-parameter scope — parameters declared on a class (class Container~T~) are recognized as bindings local to that class. Inside that class’s members T highlights as a generic parameter. The same identifier in a class that doesn’t declare it falls through to ordinary class-reference classification.
Declared classes shadow the vocabulary — a class List { } declaration in your file routes every List reference through the declared-class attribute. Navigation and rename refactoring follow the declaration site.
Type-decorator stripping — String?, int!, int[], int[8], and stacked decorators like int[]? classify the same as their underlying type, so optional / non-null / array suffixes preserve correct highlighting.
Nested generics — Map~K, V~, List~Container~T~~, Result~Order, ApiError~ all parse into a generics sub-tree where each type argument is its own PSI element, so individual arguments highlight and resolve correctly without taking the surrounding text along for the ride.
Free-form fallback — type expressions and mid-edit typos that fall outside the structured grammar still get sensible highlighting, with recognized type names retaining their classification.

classDiagram
    class Container~T~ {
        +T value
        +Optional~T~ peek()
        +map(fn Function~T, U~) Container~U~
        +int? cachedSize
        +String[] tags
    }

In the example above, T and U highlight as generic parameters, Optional and Function as built-in types, int and String as primitives / built-ins (with ? and [] decorators stripped), and Container as a declared class. Mermaid’s runtime renders all of these distinctions as identical text.

Mermaid Studio resolves class references at every declaration surface in the file, not only at relationship endpoints. A class id appearing in an attribute’s type, a method parameter type, a return type, a generic argument, a click / link / callback target, a style or cssClass target, a note for target, or an inline annotation class is treated as a live reference back to the class declaration.

What that gets you:

Go to Declaration from any reference jumps straight to the class line, no matter which surface you started from.
Find Usages enumerates every site so you can audit each place a class is referenced before changing it.
Rename rewrites every reference in one operation. Because the rewrite walks the structured tree rather than text-matching, renaming Order does not touch unrelated tokens, comments, or substrings that happen to share those letters.
The rename validator accepts dotted and backtick-quoted identifiers (com.billing.Invoice, `Order Item`) wherever Mermaid permits them.

Structure view

The Structure tool window treats a class diagram the way IntelliJ treats source code. Classes, namespaces, methods, attributes, notes, styles, classDef declarations, and each relationship type get their own icons; member rows carry IntelliJ’s standard public, private, protected, and package-private visibility badges instead of the raw +, -, #, ~ sigils, so members look the way they do on a Java file; clicking any node jumps the editor caret to the corresponding source range; and the tree expands and collapses around class and namespace bodies. The optional Package toggle groups classes by their dotted-id prefix, so a diagram with com.billing.Invoice-style names renders as a package hierarchy alongside any explicit namespace { ... } blocks.

Structure tool window showing a class diagram organized as a tree with namespaces, classes, members, notes, styles, and relationships

Gutter icons for inheritance and realization

Inheritance (<|--) and realization (<|.. / ..|>) relationships appear as gutter arrows on both the parent and subclass / implementer declarations. Click an icon to jump straight to the related class. The arrows make it easy to navigate large hierarchies without scrolling.

Visibility and modifier inlay hints

Optional inlay hints spell out member visibility (+ / - / # / ~) and modifiers (*, $) as words at the start of each member line. The hints are off by default. UML veterans rarely need them, while beginners often do. Enable them under Settings > Editor > Inlay Hints by toggling Class diagram visibility and modifier labels in the Mermaid Class Diagram group.

Class diagram with inlay hints rendering plus, minus, hash, and tilde sigils as public, private, protected, and package keywords inline at the start of each member line

Inline documentation

Hover or press F1 Control + Q on any class, namespace, classDef style, statement keyword, relationship arrow, or stereotype annotation for a structured popup. Class popups list members with their visibility and types, the enclosing namespace, classes the type extends or implements (and the classes that extend or implement it), and any styles applied to it. Type names in member rows that resolve to a class declared in the same file render as clickable links that open the popup for that class.

Syntax Highlighting

Syntax highlighting integrates directly with IntelliJ’s color scheme system, so diagram colors always match your editor theme. Every position in the language has its own attribute key (relationship arrows, annotation delimiters, visibility and modifier sigils, generic parameters, primitive vs. built-in vs. declared-class types, …) so you can tune any of them in Settings > Editor > Color Scheme > Mermaid Class Diagram.

Other notable features

A handful of smaller IDE niceties that didn’t get their own section above:

Code folding — collapse class bodies and namespace { } blocks from the gutter.
Brace matching — { and } are paired for class bodies and namespace blocks, so the matching brace highlights as the caret moves.
Formatter
Code Vision — usage counts appear inline next to each class and classDef declaration.
Color provider — hex colors inside style and classDef declarations show a swatch in the gutter and open an inline color picker.
Markdown injection — full class-diagram editing inside ```mermaid code fences in Markdown files.

Quick Syntax Reference

Defining classes

A class Name { ... } block declares a class with one member per line in the body. Each member starts with a visibility sigil (+, -, #, ~) and may end with a modifier suffix (* for abstract, $ for static). The example below puts every sigil and both modifier suffixes on a single class.

classDiagram
  class ClassName {
      +String publicAttribute
      -Money privateAttribute
      #int protectedAttribute
      ~boolean packageAttribute
      +publicMethod(String name, int count)
      -privateMethod(Money amount) Receipt
      #protectedAbstractMethod()*
      +publicStaticMethod()$
  }

Attributes use either C/Java-style +Type name (type first) or TypeScript/UML-style +name : Type (name first, colon-separated). Methods are +name(args) ReturnType or +name(args) : ReturnType. Method arguments follow the same two conventions, but inline method declarations inside a class body accept only the C-style Type name form for each argument. Generic parameters wrap in tildes: List~Order~, Map~K, V~.

Sigil reference:

Sigil	Meaning
`+` (prefix)	public
`-` (prefix)	private
`#` (prefix)	protected
`~` (prefix)	package / internal
`*` (suffix)	abstract
`$` (suffix)	static

Stereotype annotations

Annotations describe the role of a class. Four placement forms are supported:

classDiagram
  %% Standalone
  class Drivable
  <<interface>> Drivable

  %% Inside class body
  class PrintService {
      <<service>>
  }

  %% Inline on the declaration (Mermaid 11.14.0+)
  class Repository <<repository>>

  %% Inline with body (Mermaid 11.14.0+)
  class Customer <<entity>> {
      +String email
  }

Recognized stereotypes include interface, abstract, enumeration / enum, service, entity, repository, controller, utility, and any free-form text. If a class has more than one annotation, only the first is applied at render time.

Namespaces

Group related classes under a namespace { ... } block. Mermaid resolves class references by exact text match across the whole file: namespaces group classes visually in the rendered output but do not scope id lookup. A class declared inside namespace billing { class Invoice } is referenced as Invoice from anywhere in the diagram, not as billing.Invoice.

classDiagram
  namespace shipping {
      class Order
      class Item
  }
  namespace billing {
      class Invoice
  }
  Order *-- Item
  Order ..> Invoice

Nested namespaces and display labels (Mermaid 11.15.0+)

Mermaid 11.15.0 added two new namespace forms. The plugin recognizes both at any runtime and flags them on pre-11.15.0 runtimes with a version annotation.

Nested namespaces let you express a hierarchy syntactically rather than via dotted ids:

classDiagram
  namespace com {
      namespace billing {
          class Invoice
          class Receipt
      }
      namespace shipping {
          class Order
      }
  }

A bracketed display label after the namespace name renders a different label than the id in the diagram:

classDiagram
  namespace billing ["Billing Service"] {
      class Invoice
  }

Dotted names

Mermaid accepts dots in class and namespace identifiers and treats the full dotted string as one opaque id, not a navigable path.

classDiagram
  class com.billing.Invoice
  class com.shipping.Order
  com.shipping.Order ..> com.billing.Invoice

A few consequences of the flat lookup:

class com.billing.Invoice declares a class whose id is the literal string com.billing.Invoice; it does not nest Invoice under a com.billing package.
namespace foo.bar { class Baz } does not register an id foo.bar.Baz; the class is still just Baz in the lookup, and the namespace’s role is purely visual grouping.
Combining the two forms is fine — namespace com.billing { class com.billing.Invoice } is two unrelated naming choices stacked, not a qualified declaration.
Mermaid Studio’s structure view offers a Package toggle that groups classes by dotted-id prefix, so com.billing.Invoice and com.shipping.Order render as a tree even though the runtime sees flat ids.

Relationships

Syntax	Meaning
`<\|--` / `--\|>`	Inheritance
`<\|..` / `..\|>`	Realization
`--` / `--`	Composition
`o--` / `--o`	Aggregation
`-->` / `<--`	Association
`..>` / `<..`	Dependency
`()--` / `--()`	Lollipop interface
`--`	Solid link
`..`	Dashed link

Bidirectional and asymmetric forms are also accepted: <|--|>, <-->, o--o, *--*, <|-->, etc.

Cardinality and labels

classDiagram
  Customer "1" --> "*" Order : places
  Order "1" o-- "*" Item : contains

Cardinalities are quoted strings on either side of the relationship; the trailing : label describes the role.

Notes

classDiagram
  class Cache
  note for Cache "LRU eviction, 10k entries"
  note "Diagram last updated 2026-04"

Notes can attach to a specific class (note for ClassName "...") or stand alone. Inside a namespace { } block, notes attach to the namespace.

Styling

style applies properties to a single class, classDef defines a reusable style class, and cssClass applies a style class to one or more targets. Inline Class:::style works on declarations and relationship operands.

classDiagram
  class Order
  class Customer
  Customer --> Order

  style Order fill:#0f766e,color:#fff
  classDef warning fill:#fee2e2,stroke:#991b1b
  cssClass "Order,Customer" warning

Click, link, and callback

click ClassName href "url" and the URL-only synonym link ClassName "url" attach a hyperlink. click ClassName call fn(args) attaches a JavaScript callback. Both click forms accept an optional trailing tooltip; the href form also accepts a link target (_blank, _self, _parent, _top).

classDiagram
  class Order
  class Customer
  class Help
  click Order href "https://internal/orders" "Open order admin" _blank
  click Customer call inspect(customerId) "Inspect"
  link Help "https://internal/orders/help"

For the complete grammar, see the Mermaid class diagram documentation.

Previous
C4 Diagram Next
Entity Relationship Diagram

Class Diagram

Feature spotlight

Smart completions

Live templates

Class declarations

Notes

Relationships

Visual editing

Style pane

Class styling

Relationship controls

Class editor dialog

Inline label editing

Quick fixes and intentions

Structured members and generics

Navigation and rename

Structure view

Gutter icons for inheritance and realization

Visibility and modifier inlay hints

Inline documentation

Syntax Highlighting

Other notable features

Quick Syntax Reference

Defining classes

Stereotype annotations

Namespaces

Nested namespaces and display labels (Mermaid 11.15.0+)

Dotted names

Relationships

Cardinality and labels

Notes

Styling

Click, link, and callback