v31.4.2 focuses on diagramming and leaves SVG editing out
draw.io v31.4.2 is a client-side editor for general diagrams and whiteboards. The project maintains the public diagrams.net deployment, a desktop distribution, a WAR package, and source that can be served through GitHub Pages. Its repository is the application behind a familiar product rather than a small component library. That makes the editor easy to recognize, while the 493,274-line checkout takes more care to modify than the short README implies.
The scope has two explicit limits. The README says draw.io is not an SVG editor, and its SVG export is intended for embedding in web pages. It also says this edition lacks real-time collaborative editing. Those statements matter more than a long feature list: draw.io suits deliberate diagram construction and file exchange, while designers editing vector paths or groups drawing on one live canvas should start elsewhere.
What happened when we ran it
Our sandbox cloned commit 074a2ea, the v31.4.2 release commit, into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The checkout contained 3,475 files, roughly 493,274 source lines, and occupied 167.3 MB. The Node project sits under ./etc/dependencies/, which is less obvious than a package manifest at the repository root.
Installation failed with exit code 1 after 11 seconds. npm tried to fetch jsZip@3.10.1 and received a 404 from the public registry. The log then stated that the package name is invalid because names can no longer contain capital letters. The pinned manifest at commit 074a2ea contains that exact mixed-case dependency. The run stopped at installation, so it produced no build or test result.
The 53.6 MB WAR avoids the rejected npm package
Release v31.4.2 includes a draw.war asset of 53,634,352 bytes. The tagged release workflow checks out the repository, sets up Java 8, changes into etc/build, and runs ant war. For operators already running a servlet container, that package is the clearest artifact to evaluate. It also avoids treating etc/dependencies as though it were the whole application build.
A simpler standalone route serves the editor from a GitHub Pages fork. The README calls that a fully functional editor without integrations. The official container path lives in the separate jgraph/docker-drawio repository, which explains why our checkout scan found no Dockerfile here. These three routes have different maintenance costs. Static hosting minimizes server work; the WAR and container paths make more sense when integrations or controlled deployment are required.
Version 31.4.2 still excludes simultaneous editing
The current README says real-time collaborative editing is unsupported in this version. That is a firm product boundary for workshops, classrooms, and incident calls where several people need to draw at once. Excalidraw is the more natural alternative for that use. draw.io remains useful when one person edits while others review exported files, or when an organization values its diagram vocabulary more than live cursors.
Integrations add failure modes outside the canvas. Open issue 5313 reports that a self-hosted GitLab OAuth flow redirected correctly at first, then attempted its token exchange against public GitLab and returned HTTP 500. The report covers WAR versions 22.1.21 and 28.2.7 and remains open without comments. It is not evidence about every storage provider or v31.4.2, but it gives private GitLab operators a specific flow to test before rollout.
Apache 2.0 covers the code, with a separate icon restriction
The repository code uses the Apache License 2.0, and draw.io says it makes no copyright claim over diagrams users create. Bundled icon sets, stencils, and templates have an added condition: they and derivatives cannot be distributed as software assets in Atlassian products or its marketplace without written permission. End-user diagram output is exempt. Product teams embedding the asset library should read that distinction instead of assuming every bundled graphic follows the code license alone.
Contribution policy is also unusual for a public repository of 3,475 files. The core team does not accept pull requests and develops the project internally. The issue tracker and discussions remain open for editor questions and reports, but a developer cannot count on upstreaming a local fix through the usual fork-and-PR path. If your deployment needs long-lived changes, budget for carrying them or seek agreement with the maintainers first.
September 1 activity outweighs the 101-item queue
GitHub recorded the last push on September 1, 2026, and v31.4.2 was published that day. The repository had 7,874 stars and 101 open issues and pull requests when fetched. Recent release history is dense, with v31.4.1 on August 28 and v31.3.2 on August 22. Those dates show current maintenance even though the combined open count is large.
Issue activity reaches both core editing and integrations. Issue 5757, opened August 31 against v31.4.1, documents PlantUML mindmap style blocks rendering with default styling. Issue 5725 describes a Chrome and Google Drive text-box artifact, later reproduced by its reporter on version 31.1.9. The examples are narrow, but they argue for testing the exact import, export, browser, and storage paths your diagrams depend on.
The 167.3 MB source tree is for owners of a deliberate fork
A team choosing draw.io as an editor should begin with the hosted app, desktop package, GitHub Pages path, WAR, or official container repository. Clone the 167.3 MB source tree when you need a maintained fork and accept the project's no-PR policy. Mermaid and PlantUML fit source-controlled text diagrams better. Excalidraw fits shared sketching. None is a drop-in replacement for draw.io's general visual editor.
The 11-second npm failure lowers confidence in the documented source experience, not in the existence of v31.4.2 or its published WAR. draw.io is still an easy recommendation for individual and asynchronous diagram work because its boundaries are stated plainly and release activity is current. Self-hosters should use a packaged route, pin the version, test every chosen integration, and avoid basing deployment automation on the mixed-case dependency until the manifest changes.