Releases and Versioning

How draw.io versions are numbered and published, what a release contains, how the version of the web app, the desktop app and the Docker image relate, which browsers are supported, and what this means for plugins, embedders and forks that need to stay compatible.

The version number

The current version is in the VERSION file at the root of the repository, a single line such as 32.3.0.

Where	What you see
VERSION	The version of the checked-out release
EditorUi.VERSION	Declared as '@DRAWIO-VERSION@' in js/diagramly/EditorUi.js. The app target in etc/build/build.xml reads VERSION and replaces the token in app.min.js and in the viewer bundles.
Help menu	The last entry of the Help menu is the about action, labelled 'v' + EditorUi.VERSION in js/diagramly/Menus.js. In the simple and sketch themes, Help is inside the main menu.
Browser console	EditorUi.VERSION in the editor and in pages that load the viewer bundles
Development mode	With ?dev=1 the sources are loaded unbuilt, so the Help menu shows v@DRAWIO-VERSION@

mxClient.VERSION is '@MXGRAPH-VERSION@' in mxgraph/src/mxClient.js and carries a number only in the prebuilt mxgraph/mxClient.js. Use EditorUi.VERSION to identify a draw.io build.

Diagram files do not record the editor version. When it writes a file, EditorUi.prototype.getFileData removes old version, editor and userAgent attributes from <mxfile> and sets host (see File format).

Numbering and cadence

Versions have three parts, X.Y.Z, and Git tags are vX.Y.Z. A few early tags have four parts (v6.1.1.0). The data below comes from the public tags and releases as of October 2026.

• Frequent releases. There were 61 GitHub releases in the twelve months to 7 October 2026, typically several a month and sometimes two on the same day (v32.0.1 and v32.0.2).

• Regular major increments. The first releases of recent major versions:

  Major	First release
  28	v28.0.1, July 2025
  29	v29.0.2, November 2025
  30	v30.0.0, May 2026
  31	v31.0.2, July 2026
  32	v32.0.1, October 2026

• Gaps are normal. Not every version is published. The ChangeLog has sections for 32.1.0 and 31.7.1, but there are no such tags. Do not infer a missing release from a gap.

• Not semantic versioning. A major increment is not a compatibility statement for plugin authors or embedders, and a patch release can contain behaviour changes. The ChangeLog entry for 16.0.0 is an example: the major version changed because of a breaking change in the Docker image, with "no breaking change in the editor codebase".

Treat the version as a release identifier, read the ChangeLog and test before you upgrade.

What a release contains

The release commit and tag

The public dev branch is the latest release. Each release is usually a single commit titled X.Y.Z release, with an annotated tag vX.Y.Z pointing at it. Occasional maintenance commits, such as workflow changes, sit between releases. A release commit contains everything that changed since the previous release:

• the source changes
• the updated ChangeLog and VERSION
• the rebuilt bundles in src/main/webapp/js/ (app.min.js, viewer.min.js, and others) and the regenerated src/main/webapp/service-worker.js

The individual commits behind a release are not published. To see what changed between two releases, compare the tags:

git diff v32.2.0 v32.3.0 --stat
git diff v32.2.0 v32.3.0 -- src/main/webapp/js/grapheditor/Graph.js

To be notified of new releases, watch the repository with Watch > Custom > Releases on GitHub.

The GitHub release and draw.war

Pushing a v* tag runs the WAR CI workflow, .github/workflows/war.yml:

1. It checks out the tag and sets up JDK 8 (Zulu).
2. It runs ant war in etc/build.
3. It creates a GitHub release for the tag with build/draw.war attached (about 48 MB for 32.3.0).

The release has no notes; the ChangeLog is the record of changes. If the workflow fails, the tag has no GitHub release: v31.7.0 is one example. You can then build the .war from the tag yourself.

The war target depends on app and javac. It rebuilds the bundles that the Ant build produces (app.min.js, the viewer bundles, extensions.min.js and others) from the sources in the tag, compiles the servlets in src/main/server/java into WEB-INF/classes, and zips src/main/webapp into draw.war, a standard web application archive for a servlet container. See Building for the targets and Self-hosting for deployment.

The ChangeLog

ChangeLog at the root of the repository lists versions newest first, back to 2011:

06-OCT-2026: 32.3.0

- Places the width handles of the tapered arrow in model units
- Removes waypoints when an edge segment is moved back to the default route [jgraph/drawio#5761]

• Each section starts with a DD-MON-YYYY: X.Y.Z heading, followed by one - line per change. Older sections vary in date format and wording.
• Issue references are written as [jgraph/drawio#N] or [jgraph/drawio-desktop#N].
• The ChangeLog covers the whole code base, so it also lists changes to hosted services and to integrations built from the same code that do not affect a self-hosted editor.
• Section headings sometimes name versions that were never tagged (see Gaps are normal).

Products and their versions

Product	Version	Notes
app.diagrams.net	Help menu	The production deployment of this code. SECURITY.md notes that the version deployed there can differ from the latest version in this repository.
viewer.diagrams.net, embed.diagrams.net	EditorUi.VERSION in the console	Scripts and pages loaded from these hosts are whatever is deployed there, not a fixed release
draw.io Desktop	Same numbers as this repository	The desktop repository includes this one as the git submodule drawio (branch dev) and tags its releases vX.Y.Z with the version of the web release it contains. Not every web release gets a desktop release (31.6.1 and 31.4.6 are web only), and desktop releases usually follow the web release by a short time. See Desktop app.
Docker image jgraph/drawio	Image tags such as 32.3.0, without the v	Built by jgraph/docker-drawio (see below)

Docker image tags

The Docker image workflow in jgraph/docker-drawio clones the current jgraph/drawio default branch, runs ant war, and installs the war into a Tomcat 9 image for linux/amd64 and linux/arm64. It tags the image with the version from the VERSION file of jgraph/drawio:

Trigger	Tags pushed
A vX.Y.Z tag in docker-drawio that matches the current draw.io version	X.Y.Z and latest
The weekly schedule (Mondays) or a manual run on the default branch	X.Y.Z and dev

Because the scheduled build pushes the version tag again, the image behind a version tag can change (for example with a newer base image) while the draw.io version stays the same. Pin a version tag in production, or an image digest if you need the image itself to be immutable. The 16.0.0 ChangeLog entry confirms that "the docker images follow the same numbering". Configuration of the image is described in its README and in Self-hosting.

Supported browsers

The README lists the supported browsers:

Browser	Minimum version
Chrome	123
Firefox	120
Safari	17.5
Opera	109
Edge	123
WebView Android	137
Safari iOS	18.5

drawio.com refers to this list, and notes that inside a host product or integration the host's browser support applies. Check your browser against this list before you report a browser-specific bug.

Compatibility and API stability

draw.io has no versioned public JavaScript API. The code is plain scripts that define globals (mxGraph, Graph, EditorUi, App, Sidebar, and so on), and plugins and forks can reach all of it, so every internal function, prototype property and argument list can change in any release. For example, the 31.7.0 section of the ChangeLog lists "Removes the unused DrawioFile.isMovable and DriveFile.isMovable" and "Removes the unused includeCellId argument of createSvgImageExport".

Guidance for code that builds on draw.io:

• Prefer the documented interfaces. The file format, the URL parameters, the embed mode protocol, the configuration options and the plugin entry point Draw.loadPlugin are documented on drawio.com and are what integrations are built on. Use them instead of internal functions where you can.
• Pin a version. Host a specific release (a tag, a .war from the releases page, or a Docker version tag) instead of loading scripts from app.diagrams.net or viewer.diagrams.net if your code depends on internals.
• Re-test on every upgrade. Read the ChangeLog sections between your version and the new one, diff the files you override (git diff vA vB -- <file>), and test your plugin, override or fork against the new release before you deploy it.
• Override narrowly. When you change behaviour, wrap the original function and call it rather than copying its body, so upstream fixes still reach you. See Extending the editor and Plugins.
• Older readers. Diagrams saved by a newer release can use style keys that an older release does not know, for example the curveGeometry edge style added in 32.3.0. An older viewer or editor ignores such keys, so the diagram renders without that feature.

Security fixes

SECURITY.md accepts security reports only against the latest version in this repository, or the version deployed to app.diagrams.net if it differs. Fixes are not backported to older versions. If you self-host, keep your deployment on the latest release.

Fixed vulnerabilities are published as GitHub security advisories that name the first patched version. Check them when you decide whether to upgrade a pinned deployment. To report a vulnerability, see Security.

See also

• Building
• Self-hosting
• Desktop app
• Related repositories
• Contributing
• Security
• FAQ