Contributing

How to help the draw.io project as a developer or user: where each kind of report goes, what makes a bug report actionable, how translation corrections and security reports are handled, and what applies when you fork the code. Read this before opening an issue.

Pull requests: translations only

The README states it plainly: "We do not accept pull requests. The project is developed entirely by the core team." The one exception is translations: corrections to the language files in src/main/webapp/resources/ are welcome as pull requests, see Translation corrections.

If you have found a bug and know the fix, put it in the issue: the steps to reproduce, the file and function involved and the change you propose. A precise report with a diagnosis is the most useful contribution you can make.

Where to go

You have	Go to
A question about using or building on the code	Discussions, Q&A
An open-ended idea	Discussions, Ideas
A bug in the editor, the viewer, app.diagrams.net or a self-hosted instance	New issue, Bug report template
A concrete feature request	New issue, Feature request template
A security vulnerability	Private advisory, never a public issue (see Security)
A problem that only happens in draw.io Desktop	jgraph/drawio-desktop issues
A problem with the Docker image itself (entrypoint, Tomcat, certificates)	jgraph/docker-drawio issues
A problem with draw.io for Confluence or Jira	The app's support channel, not this repository (see Getting support)
A wrong or missing translation	A pull request against dia_<code>.txt, see Translation corrections

The README adds that for questions about the editor in any draw.io product, the issue tracker and discussions here are a good starting point. A bug that also happens in app.diagrams.net belongs here even if you found it in the desktop app or an integration.

Reporting a bug

Before you file

1. Search the issues, open and closed, and the discussions.
2. Check that the problem still happens in the latest release. app.diagrams.net runs a current version; for a self-hosted instance compare with the newest tag. Fixes are not backported (see Releases and versioning).
3. Reproduce it in a private window with all browser extensions switched off. The bug template asks you to confirm that you did.

Fill in the template

Use the Bug report template and fill in every section. The template warns that issues with deleted or missing parts will be closed, and the tracker has an Issue template not filled label for reports that are ignored until the template is completed.

The template asks for:

• a description of the bug, numbered steps to reproduce, and the expected behaviour
• screenshots where they help
• the draw.io version
• operating system, browser and browser version (and device for phones and tablets)
• confirmation that you tested in a private window with extensions off
• any additional context

What makes a report actionable

Item	How to get it right
Version	The last entry of the Help menu shows the version as vX.Y.Z (in the simple and sketch themes, Help is inside the main menu). In the browser console, EditorUi.VERSION returns the number.
Where it runs	app.diagrams.net, embed.diagrams.net, viewer.diagrams.net, your own deployment (say how: static files, the release .war, or the Docker image and its tag), or the desktop app. For embedding, include the URL parameters and the messages you send.
Browser and OS	Exact versions. Check them against the supported browsers.
A minimal diagram	Delete everything that is not needed to show the bug, then attach the file as a .zip, or paste the XML of the page from Extras > Edit Diagram in a fenced code block. If the content is confidential, the anonymize plugin scrambles the text of a page while keeping its structure.
Exact steps	Start from a known state (a new blank diagram or the attached file) and list every click and key press. Mention the editor theme (the ui URL parameter or Extras > Theme) and light or dark mode, because menus and panels differ between themes.
Console output	Errors and stack traces from the browser's JavaScript console. drawio.com explains how to open the console. In the desktop app use Help > Open Developer Tools.
Expected vs actual	What you expected, what happened, and a screenshot or recording of the difference.

Developers can go further: run a local checkout with ?dev=1 so stack traces point at source lines, and name the function where the behaviour goes wrong. See Getting started and Debugging.

Feature requests

Use the Feature request template: the problem you are trying to solve, the solution you would like, the alternatives you considered, and any context. Describe the problem, not only the solution you have in mind; there may be an existing way to do it, a configuration option (see Configuration) or a plugin route.

Check the scope in the README first: draw.io is a diagramming and whiteboarding application, not an SVG editor, and SVG export is meant for embedding in web pages rather than for editing in other tools.

Questions

Ask in Discussions (Q&A for help, Ideas for open-ended proposals, Show and tell for things you built). Issues are for bugs and concrete feature requests. End-user questions are usually answered by the user docs.

Security vulnerabilities

Report them privately through the repository's Security tab (Report a vulnerability), or directly at security/advisories/new. SECURITY.md asks you not to open a public issue, pull request or discussion, and to include where you can:

• a description and the potential impact
• the version or URL where you saw it
• steps to reproduce, ideally a minimal proof of concept
• relevant logs, screenshots or sample diagram files

Only the latest version (or the version deployed to app.diagrams.net, if different) is in scope. The PlantUML integration and the www.drawio.com website are out of scope. See Security for the threat model.

Translation corrections

Translations are the one place where pull requests are accepted. The process is in resources/CONTRIBUTING.md:

1. Fork the repository and edit src/main/webapp/resources/dia_<code>.txt, for example dia_de.txt or dia_pt-br.txt.
2. Change values only. Keys are managed in the English file dia.txt; do not add, remove or reorder them.
3. Keep every {1}, {2} placeholder and any markup that is in the English value.
4. Open a pull request against dev. Changes are reviewed and ship with a later release.

To find the key for a string, search for the current text in dia_<code>.txt, or open the editor with ?lang=i18n, which loads dia_i18n.txt and shows resource keys instead of text. If you have no translation for a value, leave the English text in place: an empty value shows as empty text in the editor, which does not fall back to English. A new language needs an issue first. If you cannot open a pull request, an issue with the language code, the key, the current and the proposed text and where the string appears works too. Internationalization explains the files and the format.

Stale issues

A scheduled workflow (actions/stale, daily at 11:42 UTC) processes issues and pull requests:

Step	When	What happens
Marked stale	After 100 days without activity	A comment linking the Stale bot FAQ and the wontfix label
Closed	15 days after being marked stale, if there is still no activity	Closed with the declined label
Exempt	Always	Issues with the notstale label, which maintainers apply

Both labels are applied automatically; they do not mean the issue was reviewed and rejected. Any new activity removes the stale mark and restarts the count. Comment when you have something new, such as the bug still reproducing in a named newer version with updated steps. Comments that only ask for status or "+1" fall under the behaviour the Code of Conduct asks you to avoid.

Code of Conduct

All participation is covered by the Code of Conduct, adapted from the Contributor Covenant 1.4. Besides the usual standards it lists, as unacceptable, pressing developers for priority fixes or ETAs, guilting them into working on your issue, repeating a point after a request was declined, "X app has it, why don't you?", and bumping issues or repeatedly asking for status. Maintainers may remove, edit or reject comments, issues and wiki edits that do not follow it, and may ban participants.

Forks, licence and trademarks

This section summarises the README; it is not legal advice. Read the README and LICENSE yourself.

Source code

The source code is licensed under the Apache License 2.0. You may fork, modify and redistribute it, including commercially, under the terms of that licence. Bundled third-party JavaScript libraries all have licences compatible with Apache 2.0 (no GPL or AGPL), according to the README. Related repositories carry their own licences; for example jgraph/drawio-desktop and jgraph/docker-drawio are GPL-3.0.

Icon sets, stencil libraries and templates

The README places the icon sets, stencil libraries and diagram templates under additional terms. In short, the icon sets and stencil libraries, and anything derived from them, may not be used as software assets in, distributed for use with, or incorporated into Atlassian products or products distributed through the Atlassian Marketplace or plugin ecosystem without explicit written permission. "Derived" explicitly includes conversions to other formats, traced reproductions, substantially similar images, and AI-generated images made using the icons as reference or training input.

The restriction does not apply to end-user output, such as images or documents exported from diagrams. The same text is in src/main/webapp/stencils/LICENSE. The README also says that some icons come from third-party copyright holders whose licences permit use in this project, and that no copyright claim is made on the diagrams you create.

Trademark

draw.io is a registered EU trademark (#018062448). According to the README:

• do not use the draw.io name or logo in a way that suggests affiliation with, endorsement by or sponsorship by draw.io
• do not use draw.io logos for your own business, product, project, domain or social media presence
• do not modify the draw.io logos
• any use of draw.io trademarks requires prior written permission

In practice, give a fork its own name and logo.

Keeping a fork maintainable

• The public dev branch moves one release at a time: each release is usually a single commit with a vX.Y.Z tag. Base your fork on a tag and rebase release by release (see Releases and versioning).
• Internal JavaScript APIs change between releases. Where you can, add behaviour through plugins, configuration or overrides instead of editing core files, so upgrades are smaller.
• Some committed bundles are built outside this repository and cannot be regenerated from it, for example js/stencils.min.js and mxgraph/mxClient.js. See Building before you change code that ends up in them.

See also

• Getting support
• Security
• Internationalization
• Releases and versioning
• Debugging
• FAQ
• Stale bot FAQ