el-easydraw: a drawing editor that lives inside Emacs

A drawing tool that is part of the editor

Emacs Easy Draw is a drawing tool that runs inside Emacs. That is the whole premise, and it has consequences in both directions.

What it buys you is that a diagram becomes a buffer. You do not leave your editor, do not launch a separate graphics application, and do not manage a file format that the rest of your notes cannot reference. The screenshot in the README is a GIF of the editor running in place.

What it costs is the drawing surface itself. The data Emacs Easy Draw handles is a small subset of the SVG specification, and the recommended file extension is .edraw.svg. The README is explicit about the boundary: Emacs Easy Draw cannot edit general SVG data, but the data it outputs can be viewed by web browsers and other software that can handle SVG. So it is a producer of SVG, not a consumer of it.

The requirements are correspondingly modest but specific: Emacs 27.2, image support, SVG support, gzip and gunzip or zlib support, and libxml support. The gzip requirement is explained by the data format: drawings can be stored inline as Base64 compressed data inside a link, which is the mechanism that lets a diagram live inside an Org file.

The audience is an Org mode user, and specifically one who wants diagrams to be editable in place rather than exported as pictures. The homepage is a blog post from 2021 announcing the tool, which dates the project as a personal tool that grew into a released package.

edraw-mode and the .edraw.svg file

The single-file entry point is edraw-mode.el, and there are two ways to reach it.

You can open an existing .edraw.svg file by adding an autoload and a mode association to your init file:

(autoload 'edraw-mode "edraw-mode")
(add-to-list 'auto-mode-alist '("\\.edraw\\.svg$" . edraw-mode))

The README notes a subtlety here: set this up later than other modes for .svg such as image-mode, because auto-mode-alist is consulted in order and a generic SVG handler registered first will win.

If the long extension bothers you, you can put a comment specifying the mode at the top of the file:

<!-- -*- mode: edraw -*- -->
<svg ...

Comments in files are preserved as much as possible during editing, so that marker survives a round trip through the editor. There is also a magic-mode-alist alternative that matches on the shape of the file.

For a quick sketch, the edraw command is autoloaded and simply creates a new buffer and sets its major mode to edraw-mode, which the README says is suitable for quickly creating new diagrams, with saving through save-buffer, C-x C-s. The buffer is dual nature: typing M-x xml-mode in an edraw-mode buffer edits it as XML, and typing M-x edraw-mode again returns to graphical editing.

That last point is the interesting one. A drawing file is an SVG document, so you can drop to the text representation when the graphical editor cannot express what you need, and come back.

Org mode: a diagram as an editable link

The edraw-org.el module is where the tool meets the note-taking workflow, and it is the reason most people would use the project.

Setup requires two hooks. The first loads the module and calls edraw-org-setup-default:

(with-eval-after-load 'org
  (require 'edraw-org)
  (edraw-org-setup-default))

The second is only needed if you use the org-export-in-background option with the asynchronous export function, and the reason given is specific: Emacs started in a separate process does not load org.el but only ox.el. The exporter therefore needs its own setup:

(with-eval-after-load "ox"
  (require 'edraw-org)
  (edraw-org-setup-exporter))

In use, you type a link and press C-c C-o on it to start drawing. You draw, press C-c C-c, and the data is saved in the buffer. The link notation section lists four forms, and all of them exist for a reason: bracket links, which are the idiomatic Org form; angle links; plain links; and the descriptive variant that gives the link a name.

The target of the link is either a file, with a path such as edraw:file=./example.edraw.svg, or embedded data, with a property holding Base64 content. Inline display of the drawing in the buffer is toggled with M-x edraw-org-link-image-mode, and an existing drawing is opened for editing with M-x edraw-org-edit-link, with C-c C-o and a right click as alternatives.

Regular file links are supported too: you can create a file link to an .edraw.svg and run M-x edraw-org-edit-regular-file-link on it. The README lists the trade-offs. Compared with the edraw link format, regular file links have no detailed settings for HTML export and cannot embed SVG data inside Org files, but they can be exported in many formats, and inline editing of data URI links is not implemented.

Path syntax and the Base64 data link

The link payload follows a small property syntax, documented as:

: edraw:<prop1>=<value1>;<prop2>=<value2>;...;<propN>=<valueN>

Semicolon separated key and value pairs, which is how the tool carries both the payload and its options in a single URL-shaped string.

The example given is a plain link whose data property holds a long Base64 string followed by another property whose value describes the path:

: edraw:data=H4sIAGAXVWYAA22O0Q7CIAxFf4X0XcpmYsIC+5cpCEQEA2Swvxed0RcfmtvbnttU5NWQdvchS7ClPCbEWiutRxqTwZExhp2AHZmad+H2Dxw45/jeAqlOFSthYAyI1c7Y8jGrTtnF0B0dYBaGOCVBq7TUwzmqrY+SvhRydd5LSFr94if2PftqNwljl7YLzgJNr/7n/AQMbuxHzwAAAA==;eop=1 is a red rectangle.

The eop property means end of path, and its value is the human readable description of the shape. So a drawing is stored as compressed Base64 plus a small set of named properties, and the descriptive property doubles as the alt text.

There is a documented trap in the plain link form. If Base64 data is included in a plain link, the trailing symbol, either = or +, may not be included in the range of the plain link. In that case, by specifying a dummy property at the end, you can include the entire thing in a plain link. That is a workaround for Org's plain link parsing rules running into Base64 padding characters, and the advice is to always end a plain link with a dummy property rather than relying on the link ending exactly at the Base64.

Export: HTML is the smooth path, LaTeX and ODT are not

Three export targets are documented, and the differences between them are not equal.

HTML export is the well-trodden one. There are customization variables for the HTML tag used for data links and for file links, both either svg or img, and a variable to add a viewBox attribute to svg root elements when exporting SVG. The html-tag link property selects the tag per link, so a single document can mix inline SVG and image references:

[[edraw:html-tag=img;data=<base64data>]]

LaTeX export is where the author is candid about the limits. There is a minimal implementation, but the README says plainly that they do not use LaTeX usually, so there may be some problems. It also notes that the [[edraw:data=]] format creates a temporary file when exporting as LaTeX, and invites feedback on whether there is a better way.

ODT export has the same temporary file characteristic as LaTeX, since the data links need to become an SVG file on disk for the writer to embed.

That shared limitation is the real point. Embedding a drawing directly in an Org file as compressed Base64 is excellent for a text-first workflow and for HTML output, but formats that expect a file reference need somewhere to put that file, so the exporter creates a temporary one. If your pipeline is LaTeX or ODT, the practical consequence is that the output is not a single self-contained file, and you need to know where the temporary SVG landed.

The HTML export also has a nice consequence for the web: a link with the svg tag produces inline SVG in the page, which scales and can be styled, while the img tag produces an image element.

Key bindings, file layout and release history

The key bindings section says most of them are displayed in menus and help echoes, and lists the ones that are not. Arrow keys move selected objects, with S- and a direction moving by ten pixels and C-u taking a numerical input. M- and a direction duplicates the selected objects and moves them. mouse-3 opens a context menu on shapes, anchor points, the background, the shape picker or edraw links, and C-u mouse-3 does the same while ignoring invisible or unpickable states. With the select tool, C-down-mouse-1 adds or removes the clicked shape from the selection list and M-drag-mouse-1 duplicates the dragged shape. With the path tool, C-u down-mouse-1 ignores existing points to avoid connecting or moving them. S-drag-mouse-1 gives 45 degree unit movement or square specification.

The file layout is flat and readable, with one file per concern: edraw-mode.el for the editor, edraw-org.el and edraw-org-edit.el for the Org integration, edraw-org-export-html.el, edraw-org-export-latex.el and edraw-org-export-odt.el for the exporters, edraw-path.el for the path model, edraw-shape-picker.el and edraw-color-picker.el for the palette, edraw-property-editor.el, edraw-import.el, edraw-math.el and a set of utility modules, plus a msg/ directory, a screenshot/ directory and a todo.org file.

That todo.org is a small indicator of how the project is run: the author's own to-do list lives in the repository, in the same Org format the tool integrates with.

On maintenance, the repository is not archived and the last push was on 2026-10-04. The releases are v1.3.0 on 2025-12-15, v1.2.0 on 2024-05-19 and v1.1.0 on 2023-11-16. The licence field says GPL-3.0, with the LICENSE file at the top of the tree.

One documentation detail deserves a mention because it is the sort of thing that wastes an afternoon. The README is README.org, written in Org format, and it contains raw Org syntax including link notation tables with zero-width space characters embedded to make the examples display. Reading the source rather than the rendered page is part of working with this project.

Editorial conclusion

el-easydraw suits someone who writes in Org mode and wants diagrams to live in the note as editable links rather than as exported images, with the drawing surface still inside Emacs. It does not suit a designer who needs to open arbitrary artwork, because it handles only a small subset of SVG and cannot edit general SVG data, and it does not suit a LaTeX workflow that needs reliable figure output. Before adopting, confirm your Emacs is at least 27.2 with image, SVG, gzip or zlib and libxml support, try the keybinding-free path first with the edraw command to make a quick sketch, and read the export section for your target format before committing a document to it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. misohena/el-easydraw on GitHub
3. Project website
4. README
5. Releases