Guide
Best open-source libraries for AI diagramming in 2026
Compare Eraser Diagrams, Mermaid, D2, Python Diagrams, and draw.io on layout control, routing, icons, developer experience, and licensing.
Adding AI diagrams to a product, agent, or documentation workflow starts with a practical decision: what will turn the model’s output into a useful visual? Open-source diagramming libraries let you build that step into your own software. An LLM generates diagram source, and the library renders the result.
This guide compares five options: Eraser Diagrams, Mermaid, D2, Python Diagrams, and draw.io.
What is an open-source diagramming library?
An open-source diagramming library turns a structured description of a diagram – JSON, a text DSL, Python, or XML – into a rendered image, under a license that lets you run it inside your own software. Pair one with an LLM and you have an AI diagramming pipeline you own end to end: the model writes the source, the library draws it.
Why use an open-source diagramming library?
- Choose your model. Use the LLM and prompting workflow that fit your application.
- Control deployment. Run rendering on your own infrastructure.
- Customize the output. Adapt styling, icons, and components to your product.
- Build around the source. Inspect, modify, and integrate the rendering code.
- Control rendering costs. Avoid per-diagram SaaS rendering fees while managing your own compute and model costs.
The best open-source libraries for AI diagramming
These projects range from rendering libraries to a complete diagram editor. The comparison below focuses on what matters when building AI diagramming into an application: control over the output, ease of integration, and room for customization.
| Compare | Eraser Diagrams | Mermaid | D2 | Python Diagrams | draw.io |
|---|---|---|---|---|---|
| PNG rendering setup | Node library / CLIChromium | Node library / CLIChromium | Standalone binary | Python libraryGraphviz | Full Electron application |
| Diagram source | JSON | Text DSL | Text DSL | Python | XML |
| Model output is | Data | Data | Data | Executable code | Data |
| Pre-render validation | Yes | Yes | Yes | No | No |
| Coordinate control |
|
|
|
|
|
| Built-in line routing | Yes | No | Yes | No | Yes |
| Stable across edits | Yes | No | No | No | Yes |
| Icon catalog | Available | Available | Available | Included | Available |
| Custom shape definitions |
|
|
|
|
|
| License | MIT | MITELK dependency: EPL-2.0 | MPL-2.0Including TALA | MITGraphviz: EPL-2.0 | Apache-2.0Separate asset terms |
1. Eraser Diagrams
Eraser Diagrams is an MIT-licensed framework for turning structured JSON into technical diagrams. Alongside coordinate-based composition and automatic routing, users can define custom visual components with their own HTML, CSS, and data schemas: branded service cards, rich-text annotations, and custom containers. The project overview covers the rendering model in more detail.
A model can specify positions for nodes and containers, directly expressing requests such as “put the databases on the right” or “arrange this for a presentation slide.” It can compose diagrams from your reusable components, keeping their appearance consistent across different layouts.
The included line routing algorithm connects components around obstacles, nested containers, and labels. You define the visual building blocks; the model composes them; the renderer measures and connects them.
Features
- Structured JSON authoring. Semantic nodes, connections, and containers; schema validation for checking generated source.
- Explicit placement. Coordinate-based node and container positions; editable source for targeted layout changes.
- Automatic routing. Orthogonal connections, obstacle handling, and partial rerouting that can preserve unaffected connections.
- Custom visual components. Rich text, HTML/CSS-based components, and reusable visual variants for team-specific diagrams.
- Flexible icons. Named icon lookup, access to an optional catalog of more than 4,000 icons, and support for custom assets.
- Direct integration. A Node API, CLI, and independently usable packages; PNG and HTML output, with diagram JSON available through the Node API.
Best for
- Developers adding diagram generation to AI products and agents.
- Teams producing architecture and process diagrams with consistent components and styling.
- Documentation and customer deliverables that need deliberate composition and polished visuals.
Integration
The standard rendering workflow uses Node.js and Chromium, with your own LLM supplying diagram source. The quickstart covers the API and CLI; the customization guide covers components, schemas, styles, and icons.
2. Mermaid
Mermaid turns a text-based diagram language into visuals. Its support in Markdown environments makes it a practical choice for READMEs and documentation sites, especially when a team already uses Mermaid syntax. It is also the most widely adopted of the diagram-as-code tools.
Features
- MIT-licensed JavaScript library and command-line renderer.
- Broad diagram coverage, including flowcharts, sequence diagrams, and entity relationship diagrams.
- Text source that fits naturally into version control.
- Icon support through registered packs, plus image and icon nodes in supported diagram types.
Best for
- Developers maintaining diagrams alongside code and Markdown.
- Documentation pipelines built around standard diagram types.
Limitations
In common Mermaid flowcharts, the layout engine chooses node positions. Authors can influence direction, spacing, and grouping, but the syntax offers limited direct coordinate control. Other diagram types offer more specific tools: block diagrams have grids, and architecture diagrams support alignment constraints. The available controls depend on the diagram type. Layout documentation, architecture controls.
Customization also depends on the host’s Mermaid version, configuration, and registered icon packs.
3. D2
D2 is a declarative diagramming language with multiple layout engines. It suits teams that want to maintain architecture diagrams as text and configure how those diagrams are arranged.
Features
- CLI, Go library, and JavaScript/WASM integration options.
- Multiple layout engines, including TALA.
- Automatic, explicit-coordinate, and hybrid placement through TALA.
- Engine-provided line routing; icons from URLs or local files.
- MPL-2.0 licensing, with TALA bundled as of D2 0.9.0.
Best for
- Teams already using D2 for architecture documentation.
- Developers who want a diagram DSL with configurable layout engines.
Limitations
D2’s placement behavior and available controls depend on the layout engine. Custom visuals follow D2’s language and shape system, without a schema-defined HTML/CSS component model.
4. Python Diagrams
Python Diagrams uses Python code to describe nodes, clusters, and connections, with Graphviz handling layout and rendering. Its provider icon library makes it useful for infrastructure diagrams generated from scripts and inventories.
Features
- MIT-licensed Python library with a separate Graphviz dependency.
- Bundled cloud and infrastructure provider icons.
- Custom image nodes for additional services or internal systems.
- Python functions, loops, and data transformations for repeatable generation.
- Graphviz attributes for additional layout and styling control.
Best for
- Python teams generating infrastructure documentation.
- Workflows that turn service inventories or configuration data into diagrams.
Limitations
The standard integration requires Python and Graphviz, and the model’s output is executable Python. Composition follows Graphviz’s layout model, with further control through graph, node, and edge attributes.
5. draw.io
draw.io is a complete diagram editor with a coordinate-based XML format. It is a useful choice when AI-generated diagrams need to move into an established visual editing workflow.
Features
- Browser editor, iframe embedding, and desktop application.
- Explicit coordinates and extensive manual editing controls.
- Technical shape libraries, custom images, and reusable shape libraries.
- Optional obstacle-avoiding routing; official MCP tooling for AI integrations.
- Apache-2.0 source code, with separate terms for some included assets.
Best for
- Teams already working with
.drawiofiles. - Applications where users need a full visual editor after AI generation.
Limitations
draw.io supports coordinate control, but its XML includes document structure, cell identifiers, geometry, and style attributes. Integrations generating native XML directly need to produce and maintain that scaffolding. Its embed interface also centers on an editor session and a messaging protocol, adding integration work for applications that primarily need a renderer.
Licensing requires separating the application code from its assets. The source is Apache-2.0. Reuse of included icons and stencils as software assets in Atlassian products and marketplace integrations requires written permission; this restriction does not apply to end-user diagram output. See the repository’s licensing notes.
Key features to look for
Control over composition
Check whether the model can represent layout instructions directly. “Put the database on the right” requires a way to control placement. Explicit coordinates are especially useful for presentation layouts, repeated tiers, nested groups, and targeted edits. Eraser combines that control with a component system designed for technical visuals.
Automatic line routing
Node placement is only part of a readable diagram. Connections also need paths around shapes and containers, with room for labels. Look at what happens after nodes move or text grows. Eraser measures components before routing, so connection geometry can reflect their actual rendered bounds.
Stability across edits
Diagrams get regenerated. Ask what a one-word label change does to everything else on the canvas. Where the engine owns placement, a small edit re-runs the whole layout: D2’s documentation describes TALA as “more random than other layout engines,” and notes that changing a label can cascade into an entirely different diagram. Authored coordinates avoid that, because the positions are in the source rather than recomputed. Eraser also pins unchanged connection routes by default, so a local edit stays local – which is what keeps diagram diffs and documentation pipelines reviewable.
Untrusted source handling
Generated diagram source is untrusted input, because the model that wrote it can be steered by anything it read. What matters is what your renderer then does with it. Four of these libraries consume inert data – JSON, a DSL, or XML – so a hostile document produces, at worst, a malformed diagram.
Python Diagrams is different in kind. Its source is a Python program, so rendering it executes model-authored code on your infrastructure with whatever credentials and network access that process holds. If an LLM writes that source, run it in a sandbox with no secrets and no outbound network. Rendering in a browser engine deserves a second look regardless: Mermaid exposes a securityLevel setting governing whether labels may carry HTML and click handlers, and Eraser sanitizes documents before rendering. Check which default your integration inherits.
Visual quality and customization
Assess typography, rich text, icon availability, and reusable components. A provider icon library may cover a basic infrastructure diagram; a branded product may also need service cards, annotations, and custom containers. Eraser’s HTML/CSS component support gives developers a familiar way to define those visuals.
Authoring format and developer experience
The source format shapes both model generation and subsequent edits. Evaluate its schema, validation errors, and incidental markup, along with the API or CLI you will call. Also check runtime dependencies and the path from generated source to a usable output file.
Licensing
Review the framework, its dependencies, and any icon assets separately. Eraser, Mermaid, and Python Diagrams use MIT for their libraries; D2 uses MPL-2.0; draw.io uses Apache-2.0 for its source. Dependency and asset terms can differ from the main project’s license.
Choosing a library and getting started
Start with the diagrams your application needs to produce, the visual requirements, and where rendering will run. Use those requirements to prioritize source format, layout control, customization, and integration effort. In short:
- Eraser Diagrams – you are building diagram generation into a product or an agent, and the output needs deliberate composition, custom components, and consistent branding.
- Mermaid – the diagrams live in Markdown, READMEs, and documentation sites, and standard diagram types cover what you need.
- D2 – your team already maintains architecture diagrams as text and wants configurable layout engines.
- Python Diagrams – you are a Python team turning infrastructure inventories or configuration data into diagrams.
- draw.io – users need to open the result in a full visual editor after the model has drafted it.
Test a shortlist with your own model and representative inputs. Generate a diagram, request changes to its content and layout, and render it again. Assess readability, consistency, and the amount of manual correction needed. A small working integration will help you judge how well a library fits your workflow.
A library is the right layer when you own the pipeline and want rendering inside your own software. If you would rather diagrams were persisted, searchable, and shared by a hosted service that agents connect to, compare agentic diagramming platforms or diagramming MCP servers instead.