Paste JSON — an API response, a schema, a document sample. Get an ERD or class diagram back.
Draw an ERD from this JSON API response, treating nested objects as related entities: { "order": { "id": 123, "customer": { "id": 9, "email": "[email protected]" }, "items": [ { "productId": 55, "name": "Widget", "quantity": 2, "unitPrice": 9.99 } ], "total": 19.98 } }
Try it →Draw an ERD from this JSON Schema: { "User": { "id": "integer", "email": "string", "posts": { "type": "array", "items": { "$ref": "Post" } } }, "Post": { "id": "integer", "title": "string", "authorId": "integer", "comments": { "type": "array", "items": { "$ref": "Comment" } } }, "Comment": { "id": "integer", "body": "string", "postId": "integer" } }
Try it →Draw an ERD from this MongoDB document, showing embedded sub-documents as owned entities and any ObjectId fields as foreign key references: { "_id": "...", "customerId": "...", "shippingAddress": { "street": "...", "city": "..." }, "lineItems": [ { "sku": "...", "qty": 2 } ], "status": "paid" }
Try it →Draw a UML class diagram from this OpenAPI component schema: UserDTO { id: integer, email: string, roles: string[] }, CreateUserRequest { email: string, password: string }, UserResponse extends UserDTO { createdAt: string }. Show inheritance and composition.
Try it →A deeply nested API response is hard to read as raw JSON in a doc. Paste it here and drop the resulting ERD into your API reference instead.
MongoDB and other document stores don't enforce a schema the way SQL does — pasting real document samples and visualizing the implied structure is often the only way to document what's actually being stored.
When a bug report includes a huge JSON payload, a diagram of its entities is faster to reason about than scrolling through indentation.
Sketch your planned response shape as JSON first, visualize it, and get feedback on the data model before you write a single line of backend code.
When frontend and backend teams need to agree on a payload shape, a diagram of the agreed JSON structure is a clearer contract than a Slack thread of examples.
JSON is easy to read one level deep and painful to read once it's five levels of nested arrays and objects — which is exactly when a diagram helps. This page is for pasting raw JSON (an API response, a JSON Schema, a document-database sample, an OpenAPI component definition) and getting back a visual: an ERD when the shape is relational (entities with implied foreign keys), or a class diagram when the shape is closer to a typed object model (DTOs, request/response shapes with inheritance).
The AI infers relationships from JSON structure the way an experienced backend engineer would read it: a nested object becomes an owned/embedded entity or a foreign-key relationship depending on context, an array of objects becomes a one-to-many relationship, and a field that looks like an ID reference (`userId`, `authorId`, a Mongo `ObjectId`) becomes a foreign key even without an explicit `$ref`. For JSON Schema input with real `$ref` pointers, those are honored directly.
This is a reading, not a formal schema validator — for deeply ambiguous JSON (is this nested object embedded data or a normalized reference? both are valid database designs) the AI makes a reasonable call, and you should sanity-check the cardinality it inferred before using the diagram in a real schema design doc. It shines at turning "here's a confusing 200-line JSON blob" into "here's the shape of the data" in one step.
Not sure how to phrase your prompt? Chat mode lets AI ask 2-3 clarifying questions about actors, events, and edge cases — then draws.
Read our in-depth tutorials — symbols, structures, 9 rules, and copy-paste prompt templates for real-world flows.
Describe entities and relationships. Get a Mermaid ERD with keys and cardinality.
Describe classes, attributes, and inheritance. Get a Mermaid UML class diagram.
Paste a code snippet. Get a class diagram, flowchart, or architecture diagram back.