Mermaid ERD import and export: a beginner guide
Paste Mermaid erDiagram text into Dr.ERD to open it as an editable model, finish the required columns and the two relationships, and export it back as Mermaid. The example is a three-table order model.
Current article: Import and export Mermaid ERD
1. How Dr.ERD reads and writes Mermaid
Mermaid’s erDiagram syntax describes tables, columns, and relationships as one piece of text. Dr.ERD reads a .mmd or .mermaid file, or text you paste, and opens it as an editable model, then writes the finished model back in the same text form. This guide imports a three-table order model, completes it, and exports it as Mermaid again.
- Import: open a .mmd or .mermaid file, or pasted Mermaid text, as a new model.
- Export: save the model as Mermaid text with Mermaid · MMD in the export format list.
- Standard erDiagram syntax has nowhere to write layout (coordinates), data dictionary entries, or detailed constraints such as NOT NULL, defaults, or identity. Dr.ERD appends one %% drerd-metadata-v1 comment line below the diagram on export, keeps those details there, and restores them when the file is imported back.
- Other Mermaid tools draw only the diagram and ignore that comment. Delete or change it and the Dr.ERD details it protected are lost, or the import reports a metadata verification error.
2. Copy the example Mermaid
The code below is the Mermaid text you import in this lesson. It contains three tables—members, orders, and order_items—and two relationships. The copy button on the code box only puts the text you see onto your clipboard; copying it does not create or open a file by itself. You run the import yourself in the next step.
- The source starts with erDiagram. The first line that is not blank and not a %% comment has to be exactly that, or the import is rejected.
- members ||..o{ orders reads as one member to zero or more orders; the two dots in the middle mark a non-identifying relationship.
- Write length and scale inside parentheses, such as VARCHAR(100) or NUMERIC(12,2).
- PK, FK, and UK come after the column name, as in BIGINT member_id FK.
erDiagram
members {
BIGINT id PK
VARCHAR(100) name
}
orders {
BIGINT id PK
BIGINT member_id FK
TIMESTAMP created_at
}
order_items {
BIGINT id PK
BIGINT order_id FK
VARCHAR(100) product_name
INTEGER quantity
NUMERIC(12,2) unit_price
}
members ||..o{ orders : "places"
orders ||..o{ order_items : "contains"3. Prepare a workspace folder
Work locally without an account. Dr.ERD runs in desktop Chrome or Edge with nothing to install. Choose a workspace folder and your ERD is saved as a .drerd file in that folder, not uploaded to a server by default. Editing with a team needs Google sign-in and saves team documents to the team you pick, and AI chat is optional. This lesson works with a local folder alone.
- Select Start editing to open the workspace.
- Use Choose folder to pick where .drerd files are saved.
- Allow access when the browser asks for folder permission.
- Desktop Chrome and Edge support folder picking and saving.
- To use AI chat, only messages you send after configuring your own API settings carry the current ERD context to the provider you choose.
4. Import the Mermaid text
In the file list, open the Import menu and choose Import Mermaid. The dialog asks for a dictionary language and a target database, then offers a file or pasted text. The target database is stored on the model and used for later exports, so it has to be selected before the import runs. This lesson uses PostgreSQL 18 to match the example. Choosing Text opens a paste box that starts with an erDiagram line.
- In the file list, select Import, then Import Mermaid.
- Choose PostgreSQL 18 as the target database.
- Select Text, then paste the code from step 2 into the paste box.
- Select Confirm. The model opens in the editor as a temporary model; press Save to keep it as a file in your folder.
- To import a file instead, choose Import file in the Import Mermaid dialog and pick a .mmd or .mermaid file.
- Imported tables are arranged on the canvas automatically.
- The import does not continue until a target database is selected.
- Errors are reported with a line number. Fix that line, then import again.
5. Check tables, keys, and type dimensions
The imported model has three tables and two relationships. Check that every physical name, type, and PK or FK marker matches the example, including length and scale. A relationship line does not create foreign key columns by itself, and an FK marker in Mermaid only says that a column is a candidate key: it does not say which column it references. Right after the import, both relationships have no source key and no FK pair.
- Open each table with Edit table and check the physical name and type of every column.
- Confirm that the id columns carry PK and that member_id and order_id carry FK.
- Confirm that matching types match exactly: members.id is BIGINT, so orders.member_id is BIGINT too.
- Check the dimensions: VARCHAR(100) has length 100, INTEGER has none, and NUMERIC(12,2) has length 12 and scale 2.
- Expected result: three tables (members, orders, order_items) and two relationships.
- An FK marker alone never configures a relationship. You set the source key and FK pair yourself in step 7.
- The example below is a plain erDiagram with no metadata comment, so Mermaid cannot express NOT NULL: every imported column except a primary key arrives as Nullable.
6. Make every column required
Mermaid has no way to say a column is required, so set it after the import. This lesson finishes with columns that must hold a value, so turn Nullable off for all ten columns across the three tables.
- Select a column in Edit table.
- In Column details, turn Nullable off.
- Repeat for all ten columns across members, orders, and order_items.
- A column with Nullable off becomes NOT NULL in the SQL DDL export. The Mermaid diagram does not show it, but the metadata comment in a Dr.ERD export keeps it.
- Importing a Dr.ERD-exported Mermaid file back into Dr.ERD restores this setting too. A plain erDiagram, or a file where another tool removed the comment, arrives with every column except a primary key Nullable again, so check it there.
- The example has no identity (auto-increment) column. When you insert rows, create the parent row first and supply the id values yourself.
7. Configure both relationships
The imported relationships do not yet know which parent column each child column references. Open each relationship and set its source key (Source key) and FK pair. Until you do, the relationship stays unresolved and the SQL DDL export refuses to run. Mermaid export still works in that state, but a real foreign key needs both pairs.
- Open the members to orders relationship and choose PK as the source key. PK here is members.id, and the source key list offers PK and UK entries rather than columns.
- In the FK pairs, set the id row on the left to orders.member_id. Do not leave the default Add column, which creates a new column. Keep Identifying off, then select Apply.
- Open the orders to order_items relationship and choose PK as the source key. PK here is orders.id.
- In the FK pairs, set the id row on the left to order_items.order_id. Keep Identifying off, then select Apply.
- Both relationships are non-identifying (0..N): the parent key is not added to the child primary key.
- One member can place zero or more orders, and one order can contain zero or more items.
- A missing source key, or a foreign key whose type differs from the referenced column, is reported as an error.
- The FK marker in Mermaid is only a hint. A relationship with an FK marker but no FK pair stays unresolved.
8. Save, then export Mermaid
Press Ctrl+S or Cmd+S to write the .drerd file into your workspace folder, then choose Mermaid · MMD in the export menu to save an .mmd file. The exported text looks like the example below: the same three tables and the same two non-identifying relationships written with ||..o{. You choose the save location each time.
- Press Ctrl+S or Cmd+S to save the .drerd file.
- Select Mermaid · MMD in the export menu.
- Choose where the .mmd file is saved.
- Open the exported file and confirm it still holds three tables and two relationships.
- Layout, dictionary entries, and detailed constraints never show up in the diagram body. Dr.ERD attaches the %% drerd-metadata-v1 comment on export so they survive, and restores them on import.
- Relationship names come from the model. In the example below they are places and contains.
- A name, comment, or relationship name that Mermaid cannot express stays in the .drerd project file, and the app reports that.
erDiagram
members {
BIGINT id PK
VARCHAR(100) name
}
orders {
BIGINT id PK
BIGINT member_id FK
TIMESTAMP created_at
}
order_items {
BIGINT id PK
BIGINT order_id FK
VARCHAR(100) product_name
INTEGER quantity
NUMERIC(12,2) unit_price
}
members ||..o{ orders : "places"
orders ||..o{ order_items : "contains"9. Troubleshooting
The situations that come up most often between import and export.
- Malformed header: the first line that is not blank and not a %% comment must be exactly erDiagram. Anything else reports an error at that line.
- Unsupported syntax: a relationship needs two characters on each side of .. or --, as in members ||..o{ orders. A line that does not match is reported as unsupported ERD syntax with its line number.
- Type mismatch: a foreign key column must use the same type as the column it references. orders.member_id has to be BIGINT while members.id is BIGINT.
- SQL export blocked: an unresolved relationship stops the SQL DDL export and asks you to set the source key and FK pair. An N:M relationship must become a junction table first.
- Missing required columns: a column whose Nullable switch is still on does not match this lesson.
10. Next steps
You have imported a Mermaid model, completed it, saved it, and exported it back to Mermaid. Continue with the other guides to build the same model from scratch in the editor, or to turn it into SQL DDL.
- Mermaid text pastes well into documentation and reviews, and the .drerd file reopens in the editor.
- SQL DDL export prepares the same model for PostgreSQL 18, MySQL 8.4/InnoDB, or Oracle 19c.