AI UML Class Diagram Generator from Text

Describe classes, attributes, and inheritance. Get a Mermaid UML class diagram.

Try one of these — click to open in the generator

UML class diagram for geometric shapes: abstract Shape with area() method, subclasses Circle (radius: double), Rectangle (width, height), Triangle (base, height). Each overrides area().

Try it →

Employee hierarchy with roles

Employee class hierarchy: Person (name, email, phone). Employee extends Person (employeeId, salary, hireDate). Manager extends Employee (directReports list). Contractor extends Person (contractEnd, hourlyRate). Show visibility markers and getters.

Try it →

E-commerce domain model

E-commerce domain model: Customer has many Orders. Order has many LineItems. LineItem references a Product with unitPrice and quantity. Product has category, sku, price. Show associations with cardinality and key methods.

Try it →

Payment processor with strategy pattern

Payment processing using strategy pattern: PaymentProcessor uses a PaymentStrategy interface. Concrete strategies: StripeStrategy, PayPalStrategy, CryptoStrategy. Each implements charge(amount) and refund(txId). Show interface implementation and composition.

Try it →

When to use AI UML Class Diagram Generator from Text

OOP domain model
User, Order, Payment, Invoice — the nouns of your business. A class diagram is where they live: fields, methods, relationships. Anyone joining the team gets the mental model in 30 seconds.
DDD aggregates & bounded contexts
Domain-driven design lives on class diagrams. Aggregate roots, value objects, entities, and the exact relationships between them — the diagram is the DDD spec.
Library & SDK API design
Before you publish v1.0, sketch the public API as a class diagram. Users grep the docs for the diagram to understand what's exported. Cleaner than tsdoc alone.
Refactor & migration mapping
Extract this method, move that field, collapse these three classes into one. A before/after class diagram makes the refactor reviewable at a glance — hard to hide breaking changes.
Design pattern documentation
Factory, Strategy, Observer, Visitor — every classic design pattern has a canonical class diagram shape. Reference these in your RFCs and readers recognize the pattern instantly.

Building a UML class diagram from text, from one vague sentence

A one-line prompt will give you a box for every noun you mentioned. What it guesses at is the arrows — inheritance or interface, composition or aggregation, all of which read the same in English prose. Chat mode asks about the one arrow that changes the design, draws the rest, and then lists every arrow it chose on your behalf. Here is the outbound notification service of a mid-sized SaaS, built from a deliberately vague opening line.

Draw a class diagram for our notification service.

AskUserQuestion

Do the channels share an abstract base class with the retry logic in it, or do they each implement a common interface and bring their own transport client?

Common interface, each channel owns its transport client

Abstract base class with shared retry logic

First draft. The ..|> on the three channels came straight from your answer. Every other arrow — including the *-- between Notification and DeliveryAttempt — is the model's own reading, and it says so below rather than asking.

I filled in a few things you didn't mention

Read "notification service" as the outbound delivery pipeline, not the in-app feed users read
Made DeliveryAttempt records die with their Notification (*--) rather than surviving as an audit log
Typed Notification.vars as Map<string, string> — you never said what shape template variables take
Gave Channel a supports() method so dispatch() has something to select on
Added a priority: int field to Notification
Modelled the dispatcher as owning its channels (*--), so channels die with it

Looks goodRemove 1

Dropped the priority field from Notification. The other three are still in the diagram.

Channels are registered once at boot from config and shared by every dispatcher instance — they don't die with it, so that relation is aggregation, not composition. Give the dispatcher a RetryPolicy it consults (maxAttempts, backoffMs). And don't put priority or scheduling fields back on Notification — the campaign service owns those.

Final version. One relation went from *-- to o--; the composition between Notification and DeliveryAttempt stayed, because that one you confirmed.

Five replies produced a class diagram where every arrow has a reason: ..|> for the channel contract, *-- for attempts that die with their notification, o-- for channels that outlive the dispatcher. A one-shot prompt picks an arrow for each of those too — it just never tells you which one it picked, and a wrong *-- reads as a lifecycle guarantee your code does not actually make.

Start this conversation →Opens the generator in chat mode with the first message already filled in.

Deep dive

Class diagrams are the standard vocabulary for talking about software structure. Reach for them when you need to communicate the shape of an object-oriented codebase: which types exist, what attributes and methods they have, and how they relate through inheritance, composition, and association.

Where they shine: onboarding docs ("here's how our domain model is organized"), design RFCs proposing a new class hierarchy or refactor, and technical interviews where you need to sketch out a design in the whiteboard. They're also the go-to for documenting design patterns — factory, strategy, observer, visitor all have a canonical class diagram shape that readers recognize instantly.

Mermaid's classDiagram supports the full UML notation you'd expect: visibility markers (`+` public, `-` private, `#` protected, `~` package), abstract classes and methods, interfaces via the `<<interface>>` stereotype, generic types, and every relationship (inheritance `<|--`, composition `*--`, aggregation `o--`, association `--`, dependency `..>`). It stops short of full UML — no swimlanes, no full activity semantics — which for most engineering docs is a feature, not a bug. If you need those, you're probably reaching for the wrong tool.