SVGEdit review: a browser SVG editor you can embed or self-host

What SVGEdit solves, and who it is built for

SVGEdit is a JavaScript SVG drawing editor that runs in the browser. The README describes it as "a fast, web-based, JavaScript-driven SVG drawing editor that works in any modern browser", and the repository splits it into two components: the editor UI (menus, buttons, panels) and the underlying svgcanvas library, published separately as @svgedit/svgcanvas. That split is the important part. The canvas package is meant to be usable on its own, so you can build a custom editor with your own framework instead of adopting the whole application.

The audience is therefore narrower than "anyone who wants to edit an SVG". It fits developers who need to let users draw or modify vector graphics inside a web product: annotation tools, diagram editors, simple design surfaces, admin panels that accept SVG uploads. It also fits teams that want a self-hosted drawing tool on their own infrastructure rather than sending files to a third-party service. The README states the project was started more than 15 years ago and then went unmaintained for a long period before the current team refreshed it, which explains why older versions still exist as fallbacks for abandoned features.

It does not fit someone looking for a desktop illustration program. There is no native build here. Everything is loaded through a browser, and the supported set is current Chrome, Firefox and Safari, with development and CI done in Chrome.

How the editor and the svgcanvas package fit together

The architecture is a two-layer stack. At the bottom, @svgedit/svgcanvas owns the SVG document, selection, drawing operations and the low-level editing model. Above it, the editor component wires that canvas to a UI. The repository is an npm workspace with packages/svgcanvas and packages/react-test listed under workspaces, and the build script runs vite build on each workspace before building the main application. That ordering matters: the canvas has to be built locally before the editor can resolve it.

Integration works by injecting the editor into a DOM element. The README warns that the container div "can be positioned anywhere in the DOM but it must have a numeric width and a numeric height (i.e. not 'auto' which happens when the div is hidden)". This is the single most common way an integration goes wrong, because a hidden tab or a collapsed flex parent gives the container zero measured size and the editor has nothing to draw into.

Configuration is passed through setConfig, and the README points to docs/tutorials/ConfigOptions.md for the available options. Extensions are a separate axis: the config holds extensions, noDefaultExtensions and userExtensions, so you can ship the editor with the built-in set, disable it, or load your own bundles. The repository includes a React sample extension under src/editor/react-extensions/react-test, which the README says is activated by building it and then listing its dist file in userExtensions.

Installing SVGEdit and opening the editor locally

The README gives a five-step path for hosting a local version. Clone the repository, install dependencies, build the svgcanvas workspace, start the dev server, then open the editor URL. Note that the svgcanvas build is a separate step from the top-level build, and skipping it leaves the editor unable to resolve its canvas dependency.

git clone https://github.com/SVG-Edit/svgedit.git
cd svgedit
npm i
npm run build --workspace @svgedit/svgcanvas
npm run start

The start script runs vite dev with --host --port 8000 --strictPort, and the prestart hook prints the address. The README says to access http://localhost:8000/src/editor/index.html in a supported browser. When the page loads you should see the editor shell with its menus and drawing canvas. If the port is already taken, strictPort makes the server fail rather than silently moving to another port.

For a production bundle you run npm run build, which builds the two workspaces and then the main application, followed by a postbuild step that copies static files and builds extensions. The output is what you serve from your own web server. If you only want the canvas inside an existing application, the README gives a shorter route: npm i -s '@svgedit/svgcanvas', then import svgCanvas from '@svgedit/svgcanvas'. The demos folder and the svg-edit-react repository are named as examples of that pattern.

Embedding the editor into an existing web application

Embedding is a module import plus a config call. The README's example loads the stylesheet, declares a container div, imports Editor.js, constructs the editor with the container element, calls setConfig and then init. The order is not decorative: setConfig has to run before init, or the editor starts with defaults.

<head>
  <link href="./svgedit.css" rel="stylesheet" media="all"></link>
</head>
<body>
  <div id="container" style="width:100%;height:100vh"></div>
</body>
<script type="module">
  import Editor from './Editor.js'
  const svgEditor = new Editor(document.getElementById('container'))
  svgEditor.setConfig({
    allowInitialUserOverride: true,
    extensions: [],
    noDefaultExtensions: false,
    userExtensions: []
  })
  svgEditor.init()
</script>

Two things in that snippet carry more weight than they appear to. First, the stylesheet is a hard requirement: without svgedit.css the UI renders unstyled. Second, the container needs a real height, which is why the example uses 100vh rather than leaving it to content. The allowInitialUserOverride flag lets the initial configuration be overridden later, which is relevant if your application exposes editor settings to the end user. The README does not document what happens when init is called twice on the same container, so treat the editor instance as a single mount point per div.

Where SVGEdit is the wrong tool

The honest limitation is scope. SVGEdit is an editor for SVG, not a general vector design application, and nothing in the README suggests otherwise. If your users need layered artwork, print-ready color management, or heavy path manipulation at illustration-tool depth, this is not the layer to build on.

Browser support is the second boundary. Development and CI run in Chrome, and the README says recent Chrome, Firefox and Safari versions are supported "in the meaning that we will try to fix bugs for these browsers". That is a maintenance promise, not a compatibility guarantee. For older browsers the README directs you to older versions of the package, and it asks you to open an issue if you need a specific browser version so the team can decide whether to support it in the current release. If your product must run on an old embedded browser, you are choosing between an outdated SVGEdit and no SVGEdit.

The third constraint is the container sizing rule. Because the editor needs a numeric width and height at mount time, layouts that mount it inside a hidden panel, a collapsed accordion or a lazy-rendered tab will produce a zero-size editor. That is a design consequence of the DOM injection model, and it means the mount point has to be visible and measured before init runs. There is also no desktop build and no standalone binary: the only distribution paths described are npm, the repository itself, and the Netlify and unpkg demo builds.

How SVGEdit compares with Inkscape and with hand-written SVG

The natural comparison is Inkscape, which people search for alongside this project. Inkscape is a desktop application; SVGEdit is a browser library with an editor UI on top. That difference decides most cases. If a designer needs a full illustration tool on their own machine, Inkscape is the right shape and SVGEdit is not, because SVGEdit has no native build and runs only in a browser. If you need an editing surface inside a web application, Inkscape cannot be embedded and SVGEdit can, through the Editor class and a container div.

The second comparison is writing SVG by hand or generating it programmatically. That gives you total control and zero dependencies, and for static icons it is usually the better choice. SVGEdit earns its place when a human needs to manipulate the document interactively, with selection, drawing tools and a live canvas. Its separate canvas package is the middle ground: you take the editing model without the stock UI, which is the path the README points to for building your own editor with your favorite framework.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push to master was on 2026-08-05, so the project is being worked on. The release history is uneven, though: v.7.3.3 is dated 2023-12-10, while package.json declares version 7.4.2. That gap between the latest tagged release and the version in the manifest tells you the published tags lag the repository, so pinning to a tag and tracking master are different decisions with different stability profiles.

Upgrade cost concentrates in two places. The package requires Node ^20.19.0 or >=22.12.0, so an older Node runtime blocks the build before anything else. And the README states plainly that V7 "is changing significantly the way to integrate and customize SVGEdit", which means integration code written against V5 or V6 will not carry over unchanged. If you are on an older version for browser reasons, the migration to V7 is a rewrite of the embedding layer rather than a version bump.

Licensing is MIT, with LICENSE-MIT.txt at the repository root and a licenseInfo.json file alongside it. That is permissive and imposes no copyleft obligation on your own application. This is a description of what the repository contains, not legal advice; if you redistribute SVGEdit inside a commercial product, read the licence text and the third-party entries in licenseInfo.json yourself. The README also credits Netlify for hosting the demo builds, which is a hosting arrangement for the project's own deployments, not a service your application inherits.

Editorial conclusion

Adopt SVGEdit if you need an embeddable, MIT-licensed SVG editor inside a web application, or a self-hosted drawing tool on your own server. Skip it if you want a native desktop application, a full vector illustration suite, or a dependency-free static page. Before committing, clone the repository and verify that npm i, the svgcanvas workspace build and npm run start all succeed on your Node version, since the package requires ^20.19.0 or >=22.12.0, then check that the editor renders inside a container div that has a numeric width and height rather than auto.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SVG-Edit/svgedit on GitHub