PlantUML refactoring project

[davidjgraph]

In 2025 we announced deprecation of the PlantUML project as it didn't fit into our client-side only architecture. With the advances in Claude we're now generating a PlantUML to draw.io converter project at https://github.com/jgraph/plantuml-converter/tree/main/plantuml-to-drawio

The idea will be you'll still be able to have a PlantUML round-trip image as before, just the rendering will actually be in draw.io. This will mean you'll be able to convert the image into editable draw.io if you wish.

So, the discussion can continue in jgraph/plantuml-converter#4.

[piotr-albertin]

Does it mean that mermain.js will be available within the draw.io, both desktop app and integration with Confluence?

[davidjgraph]

yes, mermaid.js is already available across all draw.io platforms.

[Giorgamose]

mermaid does not support several notation, for example C4 diagrams now are better supported in PlantUML

[jldupont-soralink]

Currently, there is no way (that I know of at least) of editing the generated diagram using the original mermaid text. Is there any plans to support this ?

[davidjgraph]

You select image instead of diagram in the mermaid dialog pull down.

[jldupont-soralink]

@davidjgraph Thank you so much !

[siddharthgoel88]

I was scared what would happen to my zillions of PlantUML diagrams that I have inserted in Confluence via Draw.io . Thankfully the support is still there till 2028 for Confluence 👍

[bakafox]

Great decision. Let PU finally rest in peace, it should've been dead years ago...

[dominikwenning]

Is there any way to get back the mermaid.js code after editing the diagram?

[davidjgraph]

#5074 (reply in thread)

[dominikwenning]

@davidjgraph Thanks, but this is how I import the code right? I mean how I can get it back after I was editing it. Like an export of the mermaid code.

[davidjgraph]

We don't have draw.io export to mermaid, but we don't have export to PlantUML either.

[ToadCodeGitHub]

@davidjgraph I have a local server running plantUML and draw.io v27.0.0 and it does not have plantuml support. What version of draw.io should I be using?

[ToadCodeGitHub]

sorry typeO v27.0.9

[arnaudroques]

Hi David, it's been a long time :-)

Thank you for your message and for your transparency.

We fully understand and respect your decision. We understand that the main technical reason is the server-side nature of PlantUML, which is fundamentally different from draw.io's client-side architecture. Mermaid.js is indeed a great alternative and is better aligned with your technical approach, even though (in our admittedly biased opinion!) PlantUML remains the more feature-rich option.

Regarding your remark about the inclusion of unrelated tools (such as the sudoku generator or Oregon Trail text adventure): if this is a significant pain point, we would be happy to consider providing and maintaining a streamlined, professional build of PlantUML containing only the core diagram generation features, without these experimental or fun additions. However, we fully recognize that the core architectural issue (server-side vs. client-side) is likely the primary factor behind your decision.

Finally, we would like to sincerely thank the draw.io team for having supported PlantUML for so many years, and for providing users with access to our diagramming technology. We appreciate the collaboration and remain available for any questions or further technical discussions, if helpful.

Best regards,
The PlantUML team

[davidjgraph]

Hey Arnaud, j'espère que tu vas bien. And thank you for providing the functionality for so long.

In terms of stripping stuff out, ultimately, it's free and it's your project. You don't owe us or anyone else anything. and my sudoku has improved.

It's certainly true that there's a large base for Plant that still uses it. A PlantUML to draw.io JS convertor would give you client-side rendering, though the import stuff would be hard...

[arnaudroques]

It's certainly true that there's a large base for Plant that still uses it. A PlantUML to draw.io JS convertor would give you client-side rendering, though the import stuff would be hard...

You’re absolutely right. For now, unfortunately, we don’t have anything truly client-side.

We experimented with two different approaches, but neither is really usable yet:

• A partial re-implementation in Haxe (https://haxe.org/), targeting only a small subset of PlantUML (specifically, MindMap diagrams).
  Haxe can generate JavaScript, so this actually produced a working pure client-side demo: https://plantuml.com/en/haxe-demo-javascript.
  However, porting the entire codebase from Java to Haxe would be a huge and time-consuming project.

• Running Java in the browser using CheerpJ (https://cheerpj.com/), which allows Java programs to run natively as WebAssembly.
  This is actually a really impressive technology.
  The demo page is here https://plantuml.github.io/plantuml.js/ but unfortunately, the performance is not sufficient for production use. The application startup literally takes several minutes, making it impractical for real scenarios.

For now, both efforts are on hold. Maybe, as generative AI and related tools improve, a new solution will eventually emerge.
But I wouldn’t hold my breath :-)

Maybe I’ll write to you again in 5 or 10 years. In the meantime, thanks again for everything!

[rehevkor5]

Both the PlantUML and Mermaid.js support suffer from the same core issues:

1. Can't see a preview rendering of the diagram, so you have no idea what it will look like / no meaningful editing. So, you end up having to use some external editor instead.
2. Can't edit the diagram after you insert it, and can't really recover the original text (unless you wanna copy it out of a JSON property)

Also, Mermaid is missing basic stuff like left-aligning the content of a text note (important to make things readable such as lists).

[davidjgraph]

2. Yes, you can, read the comments above.

[vgallegob]

Well, that is unfortunate. I really enjoy plantuml.

I think it's much more expressive for large technical diagrams.

draw.io was excelent for keeping a "book" of diagrams...

why not allow calling plantuml server? they have a public api

it's a petty.. I have soo many diagrams

[davidjgraph]

Our CSP would block replies from an unknown server.

[vgallegob]

You can call plantuml from the backend. Like a proxy. More over, you could allow me to set a custom plantuml server url optionally.

Win win. Secure, simpler, faster.

[davidjgraph]

This is an SOC 2 Type II grade system, we cannot call out to servers that we do not control or are not SOC 2 Type II themselves and we have a commercial contract in place with them.

[vgallegob]

Oh ok, my bad.

What if you run your own plantuml server with a docker image?

I don't know, I'm just brainstorming at this point. 😕

[davidjgraph]

PlantUML doesn't undergo any security reviews, a docker image isn't secure enough. Our current system maintains full invocation isolation. We just don't want to maintain it forever.

[davidjgraph]

We've moved the dates out 6 months to give users more time to adjust.

[khurtwilliams]

The deprecation of PlantUML in draw.io is more than an inconvenience — it may be a deal-breaker for enterprise users.

My team has invested in PlantUML for architecture and security diagrams. With this change, we’re left with Mermaid, which is not a one-to-one replacement and throws cryptic parse errors on even simple snippets. I don’t know Mermaid, and our teams shouldn’t have to relearn an entirely different DSL just to keep existing diagrams functional.

This puts me in a position where I now have to recommend that my employer evaluate alternative diagramming tools. If draw.io can’t maintain PlantUML support or provide a reliable migration path, we’ll be forced to move.

Please reconsider the decision, or at least:
• Keep PlantUML support available as an option,
• Provide a robust conversion tool for existing PlantUML diagrams,
• Or publish detailed documentation of what Mermaid features are supported and how they differ.

Without one of these, draw.io is effectively breaking workflows for long-time users and organisations that standardised on PlantUML.

[davidjgraph]

This is using draw.io within confluence cloud?

[mditullio]

Good to know, I understand well the reasons.
For C4, at this time, PlantUML is still better than Mermaid in generating from code a diagram that you won't to touch.
But if I come to use draw.io is for drawing it at hand (and use a generator only as starting point), so even the basic Mermaid generation is fine.

[andrey-tikhov]

Geez.
While I can understand the reasons the mermaid sequence diagram is a huge pain in the ***.
very simple example
the below works in plantUML perfectly

@startuml
skinparam shadowing false
Alice -> Bob: Authentication Request
Alice <- Bob: Authentication Request
@enduml

however in a new fancy mermaid this is not

sequenceDiagram
    Alice->>Bob: Authentication Request
    Alice<<-Bob: Authentication Request

I have to switch Bob and Alice and write like that because mermaid syntax doesn't support arrow looking back!

    Alice->>Bob: Authentication Request
    Bob->>Alice: Authentication Request

The amount of extra clicks is very irritating

[RichardFlanders]

The problem with Mermaid is that it does not render as standard UML. PlantUML was closer to the standard, but unfortunately was deprecated. Are there any other options with draw.io for text based UML diagrams?

[davidjgraph]

Thank you for those of you who have engaged constructively in this conversation. @arnaudroques Claude advanced slightly faster than we expected :).

I'll update the initial post.

[arnaudroques]

Hi David,

It's nice to hear from you.

One of the positive effects of the messages over the past few days is that they put me back in the mindset of: "It's true that it's a pity PlantUML only runs on the server side."

So I took another look at the problem and came across TeaVM . I don't have anything presentable yet, but I've done some experiments and it seems to work quite well. I think I've found the last missing piece of the puzzle that could make a JavaScript version of PlantUML possible.

There's still some work to do (but not too much, since TeaVM operates on the generated .class files). It has become my top priority, especially because I'm really eager to see the result. This would be integrated into the main branch, which could then compile either to a .jar or to .js.

I wasn't aware of https://github.com/jgraph/plantuml-converter/tree/main/plantuml-to-drawio

It's an interesting approach! And, in my opinion, a complementary one: it seems your solution generates XML objects that are more structured than a simple SVG (which is what my solution currently does).

If you like, we could keep each other updated on our respective progress, or even try to converge. On my side, my "serverless" version could generate an XML file (rather than SVG) that you could reuse. That would save you from having to re-parse the diagram text. I'm also considering adding metadata to the generated SVG to allow analysis and extraction of information (messages, actors, notes, etc.).

In short, there's a lot of work ahead, but I'm glad to see things moving!

Thanks again,
Arnaud