SQL to ER Diagram Generator
An entity relationship diagram is the fastest way to understand an unfamiliar database. Reading a thousand-line schema file top to bottom tells you what the tables are; a diagram tells you how they fit together. This tool builds one directly from the DDL you already have.
- Paste your DDL into the editor, or load one of the built-in samples.
- The dialect is detected automatically — override it with the dropdown if your schema uses ambiguous syntax.
- The diagram appears immediately, with related tables grouped into coloured containers and each line drawn to the exact column that holds the foreign key. Drag to pan, scroll to zoom, and click any column to jump to its line in the editor.
- Toggle Columns and Types to control detail, switch between top-to-bottom and left-to-right, or flip to the Mermaid view for a classic crow's-foot rendering.
- Export as SVG or PNG, or copy the Mermaid source to embed the diagram in your own docs.
What the relationship symbols mean
Cardinality is inferred from your constraints rather than guessed from column names, so the diagram reflects what the database actually enforces.
- 1
- Exactly one. The foreign key is NOT NULL, so every child row has a parent.
- 0..1
- Zero or one. The foreign key is nullable, so a child may have no parent.
- 0..N
- Zero or many — the ordinary “many” side of a one-to-many relationship.
- 1 ── 0..1
- One-to-one. The foreign key is UNIQUE, so at most one child points at each parent.
- Solid line
- Identifying: the foreign key is part of the child's primary key (a junction table).
- Dashed line
- Non-identifying: the foreign key is an ordinary column.
One case is deliberately never drawn: “one or more”. Whether a parent row must have at least one child is application logic, not something a schema can state, so asserting it would make the diagram lie.
Privacy and schema security
A database schema is internal intellectual property. Table names, column names, and the relationships between them describe how a business works — which is why pasting one into a tool that processes it server-side is often a policy violation, and why most online ER diagram tools require an account before they will show you anything.
This tool has no account, no upload, and no backend. The parser and the renderer are both JavaScript running on your machine. You can verify it: open your browser's network tab, paste a schema, and watch the diagram appear without a single request. Disconnect from the internet after the page loads and it still works.
The only feature that puts your schema anywhere else is the optional Share link, which encodes the DDL into the URL fragment. It never generates anything until you confirm, and it is described in full in our privacy policy.
Frequently asked questions
Does this tool explain the schema, or just draw it?
Both. An Insights button opens a plain-English summary — hub tables, many-to-many junctions, self-referencing hierarchies, one-to-one links, tables with no relationships, and tables with no primary key — plus a set of ready-to-copy sample SELECT/JOIN queries generated from your actual foreign keys. Everything is computed with simple rules from the parsed schema — no AI, nothing leaves your browser.
Is my database schema uploaded anywhere?
No. The DDL is tokenized, parsed, and rendered entirely by JavaScript running in your browser. There is no API call and no server round trip, so you can safely paste an internal production schema. The one exception is the optional Share link feature, which encodes your DDL into the URL fragment — it is opt-in, warns you before creating anything, and is documented in our privacy policy.
What SQL dialects are supported?
PostgreSQL, MySQL/MariaDB, SQL Server (T-SQL), SQLite, BigQuery, and standard ANSI SQL. The dialect is auto-detected from the text, and you can override it. Real pg_dump --schema-only, mysqldump --no-data, and SSMS Generate Scripts output all work directly.
Can I paste a whole migration file or database dump?
Yes. Statements that are not table definitions — CREATE INDEX, CREATE VIEW, INSERT, PRAGMA, GRANT, and so on — are counted and skipped silently rather than reported as errors. Only CREATE TABLE and ALTER TABLE contribute to the diagram.
What happens if part of my DDL is malformed?
Each statement is parsed independently, so one broken table does not stop the rest. The problem is reported with its line number in the issues panel, and clicking it jumps to that line in the editor. Unrecognized vendor-specific column modifiers are skipped rather than treated as errors.
How are the relationship symbols decided?
From the constraints themselves. A NOT NULL foreign key is marked 1; a nullable one is 0..1. The many side is 0..N. If the foreign key columns are covered by a UNIQUE constraint or form the child's entire primary key, the relationship is one-to-one. A solid line means the foreign key is part of the child's primary key. We never draw 'one or more', because DDL cannot express that — whether a parent must have at least one child is application logic, not something a schema states.
Why are the tables grouped into coloured boxes?
Groups are detected automatically: any set of tables joined by foreign keys, directly or indirectly, forms one group. That makes the natural subsystems of a large schema visible at a glance without any manual tagging. Tables with no foreign keys at all are collected into a single muted 'Unlinked tables' container, and a schema with no relationships is not boxed at all.
Why do the relationship lines point at specific rows?
Each line starts at the exact column that holds the foreign key and ends at the column it references, so you can see which field joins to which without reading the DDL. For a composite foreign key the line anchors to the first column; every participating column is still marked FK.
What is the difference between the Interactive and Mermaid views?
Interactive is the default: a pannable, zoomable diagram with 1/0..N notation, grouped containers, and lines anchored to individual columns. Mermaid renders the same schema as a standard crow's-foot ER diagram and lets you copy the erDiagram source to embed in GitHub, Notion, or Obsidian. Both read the same parsed schema, and the Columns, Types and direction toggles apply to both.
Can I export the diagram?
Yes — download it as SVG or PNG (at 1x, 2x, or 3x, with a light, dark, or transparent background), copy the generated Mermaid erDiagram source to paste into GitHub, Notion, or Obsidian, or copy the parsed schema as JSON for use in other tooling. The SVG is true vector, drawn from the same layout as the screen, so it stays sharp at any size.
Why do very large schemas show only some tables?
Automatic ER layout becomes unreadable past roughly 60 tables, so the diagram shows the connected tables first and offers a 'Render all anyway' button. Turning off Columns also helps a lot — a relationship-only diagram stays legible far longer.
Related tools
- DDL to ER Diagram — starting from a migration file or a database dump? This focused view covers exactly that.
- SQL to ER Diagram Generator — the same tool, framed around generating a diagram to document or explain a schema.
- Format SQL Online — tidy up the DDL before you diagram it.
- FileSQL — drop a CSV or JSON file and query it with SQL in your browser.
- Markdown Viewer — paste the exported Mermaid source to preview it alongside your docs.
- Text Diff Checker — compare two versions of a schema line by line.
- Back to Unformat.online homepage