Hardcore Reviews
Hardcore Reviews

AI Diagram Tools Compared: After Generation, Who Owns It

This review skips image quality and compares only what can be objectively verified, opening with its scope and boundary statement: not a hands-on benchmark, data verified from each project's official repository on 2026-09-15, star counts moving in real time, and no subjective quality scoring. It lines up five projects: cathrynlavery/diagram-design (39,807 stars, MIT, HTML, 44 open issues, created 2026-04-16), mermaid-js/mermaid (90,244 stars, MIT, TypeScript, 1,785 open issues, created 2014-11-01), excalidraw/excalidraw (131,918 stars, MIT, TypeScript, 3,471 open issues, created 2020-01-02), terrastruct/d2 (25,416 stars, MPL-2.0, Go, 528 open issues, created 2022-09-05) and plantuml/plantuml (13,313 stars, LGPL-3.0, Java, 588 open issues, created 2010-11-04). The analytical frame is three paradigms: text engines (Mermaid, D2, PlantUML, where authors describe structure and the engine owns layout, at the cost of layout control and a rendering dependency), self-contained artifacts (diagram-design, where a coding agent emits offline-openable HTML with inline SVG, at the cost of a heavy drawing spec), and hand-drawn interactive tools (Excalidraw, strong for human whiteboarding, where an agent produces a scene file rather than a finished image). The core claim: what you buy in a diagram tool is not generation, but who owns the artifact afterward, what form it takes, and who can open it. It closes with a selection table by team shape, and stays honest about evidence: licenses are described by type and distribution implications without absolute commercial conclusions, and the problem-density section explicitly states it is not a quality verdict, since the three differ enormously in size, age and feature surface.

Published September 15, 202610 min read
<!-- ai-diagram-tools-comparison-review | review | AI Diagram Tools Compared: After Generation, Who Owns It -->

Set the scope first: what this review compares, what it does not, and when and where the numbers came from. This is not a hands-on benchmark. Every star count, license, primary language, open-issue count, creation date, and last-push date was verified on 2026-09-15 against each project's official GitHub repository and documentation. Star counts move in real time, so by the time you read this they may have shifted; we use them only as a rough signal of scale, never as a conclusion.

We compare exactly five objectively verifiable dimensions: architecture paradigm, dependencies and runtime, output form and portability, license type, and maintenance activity with issue density. We deliberately do not score visual quality. The reason is simple: visual quality is subjective, there is no shared ruler, and a forced score would only become marketing copy for vendors while giving readers nothing transferable. Every number in this article comes from the verified data above. We do not invent, estimate, or extrapolate trends.

One caveat up front: later we note that diagram-design has far fewer open issues than the others, but that is not a quality verdict. diagram-design was created in April 2026, whereas mermaid dates to 2014 and excalidraw to 2020. Their scale, age, and feature surface differ enormously, and a young repository simply has not accumulated issues yet. Read every number below with that limitation in mind.

Scope and Boundaries of This Review

This section is the foundation. We chose these five not as direct competitors but because together they cover three places where the cost of producing a diagram lands in 2026: an engine to render it, a spec to define it, or a whiteboard to sketch it. One table compares where the cost lands, not which looks prettier.

Why we stress that this is not a hands-on benchmark. Benchmarking needs a uniform environment, inputs, and judging criteria, yet diagramming depends too heavily on the use case: an executive architecture diagram and a coworker technical sketch are measured by different standards. We will not invent a fake test bed, so we verify only what is objectively verifiable and leave the judgment to your scenario.

Why we do not score visual quality. Visual quality has no ruler, and a subjective score would only become vendor ad copy while giving readers nothing transferable. The value here is laying out verifiable dimensions so you do the multiplication for your scenario, not us handing down a conclusion that may not fit you.

Data freshness also matters: 2026-09-15. Stars, issues, and push dates all change. This article does not promise they are still exact when you read it; it only promises they are what we verified at that point in time.

The Five Projects at a Glance

Here is the verified hard data from 2026-09-15, collapsed into one table, with a one-line positioning note after it.

ProjectStarsLicenseLanguageOpen issuesCreatedLast push
cathrynlavery/diagram-design39,807MITHTML442026-04-162026-09-10
mermaid-js/mermaid90,244MITTypeScript1,7852014-11-012026-09-14
excalidraw/excalidraw131,918MITTypeScript3,4712020-01-022026-09-14
terrastruct/d225,416MPL-2.0Go5282022-09-052026-09-13
plantuml/plantuml13,313LGPL-3.0Java5882010-11-042026-09-14

One-line positioning: diagram-design is a self-contained-output project from 2026 that stresses double-click to open; mermaid is a browser text engine with the most mature docs-embedding story; excalidraw is a hand-drawn whiteboard built for collaborative sketching; d2 is a standalone Go compiler for architecture diagrams from text; plantuml is the oldest of the three text engines, in Java, with the longest history.

Two counterintuitive points. First, the highest-starred excalidraw and the lowest-starred plantuml differ by nearly ten times, yet they belong to different paradigms with different audiences, so stars do not convert into which is better. Second, diagram-design is the newest yet already past thirty-nine thousand stars, which says the self-contained-output route has real demand in 2026 rather than being a niche toy.

Three Paradigms, Three Places the Cost Lands

These five projects split into three paradigms, and the cost lands somewhere different in each. Understanding this matters more than any comparison table.

Text-engine class: mermaid, d2, plantuml. The input is a text DSL and the output depends on an engine to render it. The author describes only structure and relationships, and the layout is left to the engine. The cost is that the layout is not under your control and the output usually depends on a specific renderer or runtime. mermaid runs in the browser and uses client-side JavaScript to turn text into SVG; d2 is a standalone Go compiler from 2022 under MPL-2.0; plantuml is in the Java ecosystem under LGPL-3.0 and the oldest of the three, from 2010.

The upside of the text-engine class is a low writing barrier: a few lines of DSL produce a diagram, which suits engineers jotting things down. The downside comes from the same place: what you hand over is source code, and the picture you see is the renderer's output. Once the renderer is absent or its version changed, your picture and your colleague's may differ, which is a hard flaw for long-term archiving or external delivery.

Self-contained-output class: diagram-design. It does not render through an engine; instead it lets a coding agent emit a self-contained HTML file with inline SVG, with no build step, no JavaScript, and no external image dependency, openable by double-click and viewable offline. The cost is that it is a fairly heavy drawing spec: only one accent color, no shadows, corner radius no larger than 10px, and every coordinate and spacing must be divisible by 4. The onboarding cost is higher than writing a few lines of DSL.

The upside of the self-contained-output class is that the artifact is your own file, tied to no runtime, and still opens by double-click ten years later. The downside is the heavy spec: the first diagram takes more thought than a snippet of mermaid, and the look must obey the project's design system. That is not bad, but it constrains free-form authors.

Hand-drawn interactive class: excalidraw. A whiteboard with a hand-drawn feel, strong at collaborative human-to-human sketching. What the AI emits directly is its scene file (.excalidraw and .excalidraw.json) rather than a finished image, so delivery still needs the recipient to have the same editor or to export again. It fits the moment an idea is unsettled and a group draws it clear together, not the handover of a one-shot final draft.

Four Verifiable Dimensions

We now walk the four dimensions on verified data, with no subjective scoring.

Rendering and runtime dependency: mermaid depends on browser JavaScript; d2 is a standalone binary from the command line; plantuml needs a Java runtime; excalidraw depends on its front-end editor; diagram-design's output is plain HTML with inline SVG, openable with no runtime.

Output form and portability: the text-engine class produces source text plus a renderer, and without the renderer you see no picture; diagram-design's output is the file itself, the most portable; excalidraw's output is a scene file that needs an editor to restore into a picture.

License type and its distribution meaning: diagram-design, mermaid, and excalidraw are MIT; d2 is MPL-2.0, a weak copyleft whose obligations fall mainly at the modified file; plantuml is LGPL-3.0, also weak copyleft that generally permits library use by a larger program but conditions modification and redistribution. Before you ship, defer to each project's LICENSE file. We only say the license types and their redistribution and embedding demands differ; we do not deliver an absolute verdict on commercial use.

Maintenance activity and issue density: the table below contrasts verified stars with open issues. Reminder: not a quality verdict; creation time and scale differ enormously.

ProjectStarsOpen issuesCreatedLast push
diagram-design39,807442026-04-162026-09-10
mermaid90,2441,7852014-11-012026-09-14
excalidraw131,9183,4712020-01-022026-09-14
d225,4165282022-09-052026-09-13
plantuml13,3135882010-11-042026-09-14

The last-push dates all cluster between 2026-09-10 and 2026-09-14, which says all five were under active maintenance at verification time, with none visibly abandoned. Putting issue count next to stars, diagram-design has about thirty-nine thousand stars and only 44 open issues, whereas mermaid has over ninety thousand stars and 1,785, and excalidraw has over one hundred thirty-one thousand stars and 3,471. The gap is striking, but it must return to the limiting condition: diagram-design is only five months old, while the other two were created twelve and six years ago, with completely different scale and feature surface. Few issues are a consequence of youth, not of quality.

The Cross-Paradigm Interop Layer

This layer is unique to diagram-design and the most worth discussing. It offers three import-and-redraw channels for draw.io, mermaid, and excalidraw, redrawing an existing source file into its own design system rather than asking you to start from zero.

Supported inputs: draw.io's .drawio, .drawio.xml, .drawio.png, .drawio.svg (including compressed payload); mermaid's .mmd, .mermaid, and mermaid code blocks in Markdown; excalidraw's .excalidraw and .excalidraw.json (its png/svg exports are not supported).

It explicitly states that it does not inherit the source file's coordinates, palette, fonts, draw.io's angled connectors, mermaid's auto-layout, or excalidraw's hand-drawn geometry; it always inherits components, relationships, grouping, and direction. Each import emits a fidelity ledger that lists what was merged, collapsed, or dropped, so the process is auditable instead of a black box.

The redraw carries four knobs: Format (html, svg, png, html+png), Size (nine tiers such as doc-inline, slide-16x9, social-og, print-a4-landscape, changing both viewBox and the font ladder), Detail (faithful up to 24 nodes, balanced up to 12, simplified up to 7, pruned along a fixed ladder), and Audience (engineer, mixed, executive, changing wording but not count). These knobs make recruitment controllable rather than a hope.

A tension worth commenting on: its tagline literally reads No Mermaid slop, yet it offers a mermaid import channel. Criticizing and coexisting at once, it wants not to kill mermaid but to recruit existing mermaid assets into its own design system. For teams with large mermaid legacies who also want a unified visual spec, this is a plus: a painless migration path instead of a forced choice.

For related reading on agent workflows, see AI coding skill frameworks compared, Claude Code vs Cursor vs Codex, and Kimi vs Qwen vs GLM long context. From the same batch, diagram-design resource and diagram-design Claude Code SOP extend the topic.

Selection Advice and the Bottom Line

Advice by team shape, collapsed into one table.

Team shapeSuggested approachReason
Solo documentationmermaid or diagram-designmermaid is fast to learn and mature; diagram-design fits when you want a unified look and portability
Team embedding docs oftenmermaidits renderer has the most mature embedding story, with easy collaboration and version control
Diagrams for executivesdiagram-designunified design system, portable, viewable offline, suited to external delivery
Multi-person whiteboardexcalidrawhand-drawn sketching and live collaboration are its home turf
Large mermaid or draw.io legacydiagram-design import-redrawrecruit legacy assets into one design system, with an auditable fidelity ledger

The bottom line: choosing a diagram tool is not buying whether a diagram can be generated, but buying who owns it after generation, in what form it exists, and who can open it. The text-engine class puts the cost on the render chain and its output is the engine's; the self-contained-output class puts the cost on the drawing spec and its output is your own file. The real AI-era variable is not how good the picture looks, but whether an agent can write a deliverable artifact in one shot and whether that artifact still opens without you. Think that through and the choice gets easy.

FAQ

Q1: Is this review a hands-on benchmark? A1: No. This review is not a hands-on benchmark. All numbers come from verifying each project's official repository and documentation on 2026-09-15. Star counts move in real time and serve only as a rough scale signal.

Q2: diagram-design has the fewest issues, so is it the highest quality? A2: Not a quality verdict. It was created in April 2026, whereas mermaid dates to 2014 and excalidraw to 2020. Their scale, age, and feature surface differ enormously, and a young repository simply has not accumulated issues yet.

Q3: Can Mermaid and diagram-design be used together? A3: Yes. diagram-design offers a mermaid import-redraw channel supporting .mmd, .mermaid files, and mermaid code blocks inside Markdown, redrawing the source into its design system and emitting a fidelity ledger.

Q4: Can these projects be used commercially? A4: We only say the license types differ and their demands on redistribution and embedding differ. Before shipping, defer to each project's LICENSE file. MIT is the most permissive; MPL-2.0 and LGPL-3.0 are weak copyleft with obligations at the file level and the library-call level respectively.

Q5: Can Excalidraw's AI output be delivered directly? A5: The AI emits a scene file (.excalidraw and .excalidraw.json) rather than a finished image, so delivery still requires the recipient to have the same editor or to export again. It is not suited as a one-shot deliverable file.


Reference sources

This article is AI-assisted and human-edited. Last updated: 2026-09-15

FAQ

Is this review a hands-on benchmark?
No. This review is not a hands-on benchmark. All numbers come from verifying each project's official repository and documentation on 2026-09-15. Star counts move in real time and serve only as a rough scale signal.
diagram-design has the fewest issues, so is it the highest quality?
Not a quality verdict. It was created in April 2026, whereas mermaid dates to 2014 and excalidraw to 2020. Their scale, age, and feature surface differ enormously, and a young repository simply has not accumulated issues yet.
Can Mermaid and diagram-design be used together?
Yes. diagram-design offers a mermaid import-redraw channel supporting .mmd, .mermaid files, and mermaid code blocks inside Markdown, redrawing the source into its design system and emitting a fidelity ledger.
Can these projects be used commercially?
We only say the license types differ and their demands on redistribution and embedding differ. Before shipping, defer to each project's LICENSE file. MIT is the most permissive; MPL-2.0 and LGPL-3.0 are weak copyleft with obligations at the file level and the library-call level respectively.
Can Excalidraw's AI output be delivered directly?
The AI emits a scene file (.excalidraw and .excalidraw.json) rather than a finished image, so delivery still requires the recipient to have the same editor or to export again. It is not suited as a one-shot deliverable file.

Related

Hardcore Reviews

Open Source Is Not a License to Sell: World Models Audited

This review skips image quality and runs four ledgers instead, on selecting among open world-model and spatial-intelligence projects (explicitly scoped apart from our image capability review, the batch-23 agent long-context cost ledger, and the batch-24 voice cloud-versus-local ledger): openness of code and weights, the commercial boundary of the license, the hardware bar, and data and control. Using 2026-09-14 GitHub API snapshots it compares seven options: Robbyant/lingbot-world-v2 (1,755 stars, CC BY-NC-SA 4.0, non-commercial; 8 GPUs for 14B and 2 for 1.3B per the repo), closed-source Genie 3 (public-report specs of 720p at 24fps, about one minute of consistency, no multiplayer), bilawalsidhu/gods-eye-view (32,399 stars, MIT, runs in the browser), Robbyant/lingbot-map (17,022 stars, Apache-2.0, ECCV 2026 oral, streaming 3D reconstruction), Robbyant/lingbot-world v1 (4,449 stars, Apache-2.0) and others. Three claims anchor it: open source does not mean commercially usable, since a non-commercial license is a hard boundary; these projects live on different layers, generative, reconstruction and front-end aggregation, so the first question is which link you need; and the hardware claims contradict each other across README examples, repo scripts and media, so budget from the official repository. Includes a comparison table and selection advice for three readers: individual researchers, small teams, and commercial integrators.

Sep 14, 20269 min read
Hardcore Reviews

Cloud vs Local Voice AI: A Cost and Control Showdown

This review ignores capability and runs the cost-and-control numbers on two routes for voice AI: the cloud real-time speech API versus local open-source tooling (explicitly scoped apart from our 8-26 image-model capability review, batch-22 image cost ledger, and batch-23 agent long-context cost ledger). It opens by arguing voice cost is harder to model than text or images: real-time behavior, concurrency, duration distribution, language/dialect coverage, and privacy compliance stack five dimensions at once. It then compares the two routes dimension by dimension - unit price and billing, latency and real-time, privacy/compliance, controllability/customization, language coverage - pitting cloud representative GPT-Live-1 (closed-source, metered, real-time out of the box) against local representative VoiceStudio (open-source, one-time compute, data stays local, engines swappable), with a five-dimension scorecard and a five-scenario selection table, and concludes by scale: individual, small team, bulk. Every unit price is symbolic (P_cloud / C_local) or marked "per official pricing page"; magnitude judgments are engineering estimates. Cold take: a vendor's "pay-as-you-go saves" only covers the one workload inside its chosen sweet spot; concurrency N, duration distribution T, and mandatory real-time decide the actual bill, so measure yourself.

Sep 13, 20269 min read
Hardcore Reviews

Agent Context Cost Review: Accounting for Every Tool Call

This review ignores capability and runs the numbers instead, on the context cost of agentic long-context and multi-turn trajectories (explicitly scoped apart from our 8-26 image-model capability review and the batch-22 image cost piece). It opens with a reproducible per-turn cost formula and makes the point that the resident prefix is the portion you re-pay on every single turn. It then compares five levers - prefix caching, KV Cache compression and sparse attention, context compression, tool-output trimming, and switching trajectory replay to incremental commit - across payoff magnitude, implementation cost, risk and fit, with a five-lever comparison table plus a cost-structure table for three scenarios (a ten-tool-call single task, a long-trajectory coding agent, and batch offline work), then ranks the levers by scale: individual, small team, and bulk. Every unit price is either symbolic (P_in / P_out / P_cache) or marked "refer to the official pricing page"; magnitude judgments are labeled engineering estimates, never passed off as benchmarks. Cold take: a vendor's "cost down X%" is usually the optimum under one specific workload - cache hit rate, context distribution and tool-output length decide your bill, so instrument your own stack rather than trusting launch numbers.

Sep 10, 20269 min read