DrawPen: a cross-platform Electron overlay for annotating your screen

What DrawPen is, and the tool set it actually ships

DrawPen is described in the package metadata as a screen annotation tool built with web technology, and the README calls it an open-source screen annotation tool available on macOS, Windows and Linux. The homepage is drawpen.app, the licence is MIT, and the primary language is JavaScript.

The tool set is what you would expect from this category and it is worth enumerating because the keybinding table is the clearest description of the application in the whole README. There is a pen, activated with P or 1. There are shapes, arrow, square and the rest, with A, R, O or 2. There is text with T or 3. There is a highlighter with H or 4, which is the transparent ink used to emphasise rather than to draw. There is a laser pointer with L or 5, the transient dot that fades, which is the mode you use when you want to point at something without leaving a mark. There is an eraser with E or 6. Colour switches with 7, thickness with 8.

On top of the drawing tools there is a whiteboard, toggled with CMD/CTRL + E, and the toolbar itself can be hidden with CMD/CTRL + T, which matters when you are annotating a full screen and want the drawing out of the way. Clear Desk with CMD/CTRL + K wipes the annotations, settings with CMD/CTRL + comma, and a Reset to original action that puts keys, colours and toolbar position back to their defaults.

The pointer mode has its own animated demo in the README, separate from the main usage gif, which suggests the pointer is treated as a first-class mode rather than a variant of the pen.

The audience is anyone who presents or explains on screen: teachers marking up a shared document, a developer walking a colleague through a bug on a shared screen, a team doing a design review. The global shortcut CMD/CTRL + SHIFT + A is what makes it usable in that setting, because the whole point is to summon the tool over whatever is on screen without alt-tabbing.

The Electron stack, and the drawing library underneath

The package.json shows the architecture clearly, and it is a modern Electron application rather than a web page in a wrapper.

The runtime is Electron 44.4.3, and the build is Electron Forge with a webpack plugin, with the forge configuration in tools/forge/forge.config.js. The main entry is .webpack/main, which is the webpacked main process, and the front end is React, since @babel/preset-react and the CSS and style loaders are present along with sass and sass-loader for styling.

The dependency list is where the interesting engineering decisions sit. perfect-freehand is the stroke library, and it is the reason the lines look the way they do. It is a pressure-sensitive vector stroke library that produces tapered, natural-looking strokes from pointer input rather than a constant-width polyline, and it is the same approach used by several well known whiteboard tools. lazy-brush is the smooth-line renderer built on top of that, which is the component that draws the stroke smoothly rather than as raw pointer samples. ntcjs provides named colour conversion, which is what makes the colour switcher work across a palette. lodash.throttle keeps the pointer event handling from redrawing on every single event, which is the difference between a pen that feels laggy and one that does not. electron-store persists the settings, so keys, colours and toolbar position survive a restart, and electron-squirrel-startup handles the Windows installer lifecycle.

The dev dependencies tell the rest of the story. @electron/notarize and @electron/osx-sign are the macOS code signing and notarisation tools, and the forge makers cover maker-deb, maker-dmg, maker-rpm, maker-squirrel and maker-zip, which is the set of formats for Linux, macOS, Windows and a plain zip respectively. The publisher-github maker and the publisher-github plugin are what push a release to the repository's releases page.

There is also a release script distinction. The scripts include package_no_sign, which runs electron-forge package with -- --no-sign, and package, which does not. That flag exists so a local build can be produced without a signing identity, which is the difference between a contributor being able to produce a runnable build and not.

Installing: release artefacts, Homebrew, Scoop, and the Linux package

The primary route is the releases page, and the README links the three platform artefacts directly, which is unusual and convenient. The Windows download is DrawPen.Setup.exe, the macOS download is DrawPen-0.0.59-arm64.dmg, and the Linux download is drawpen_0.0.59_amd64.deb. Note the architectures: the macOS artefact is arm64, and the Linux artefact is amd64, which is worth checking against your machine before you download rather than after.

Package managers are the second route, and the README gives two:

# macOS (Homebrew)
brew install --cask drawpen

# Windows (Scoop)
scoop bucket add extras
scoop install extras/drawpen

No Linux package manager line appears in the README, even though a .deb artefact is published, so on Linux the practical choice is the .deb file or the rpm, since maker-rpm is in the build configuration.

Building from source is the third route, and the repository gives you the shape of it. The scripts are start, which runs electron-forge start with NODE_ENV=development, package, make for installers, and publish. The forge config is referenced from ./tools/forge/forge.config.js, and the tools/ directory at the top level is where that lives. The engines field pins node to >=22.22 <23, and the repository carries an .nvmrc file, which is how you get the right Node version without guessing. The .npmrc at the top level is the npm configuration for the project.

The .nvmrc plus a narrow engines range is a detail that matters more than it looks. An Electron application that pins a specific Node major version and a specific Electron version is a project where the toolchain is part of the product, and a contributor on the wrong Node version will hit a failure that has nothing to do with their change.

The Wayland segmentation fault, and the two workarounds

The known issues section of the README is the most valuable thing in it, and it deserves to be read before installation rather than after a crash.

On some Linux setups running Wayland, for example Fedora KDE Plasma and Zorin, DrawPen may start with a segmentation fault. The README links issue 82 for Fedora KDE Plasma and issue 81 for Zorin, and then links an explanation hosted in another project's documentation, a teams-for-linux write-up on the Wayland, X11 and Ozone platform investigation. That link is worth following, because it says the fault is not really DrawPen's bug in the ordinary sense. It is a consequence of how a Chromium-based application is expected to talk to a Wayland compositor, and Electron applications in general can hit the same path.

Two workarounds are given. The first is to run the app with the X11 backend:

drawpen --ozone-platform=x11

The second is to use the drawpen-x11 package, which is available from the releases page. So the project's answer is that on a Wayland desktop, you either force the X11 path yourself or you install a build made for it.

The wider point is worth making for anyone evaluating a screen annotation tool. A tool that draws over your screen is a tool that needs to capture the screen, and on Linux, screen capture and global input handling are exactly the two areas where Wayland's permission model differs sharply from X11's. Under X11, an application can read the root window and grab global keys with little friction. Under Wayland, both require a portal and explicit user permission. An Electron application that assumes X11 behaviour will therefore either fail, as here, or prompt in ways that vary by compositor. The documented failure is honest, and the two workarounds are practical, but a buyer on a Wayland-only distribution should treat the X11 requirement as a condition rather than a preference.

The pointer mode and the whiteboard are also worth noting here, since both are the features that interact with the desktop rather than with the drawing surface.

Versioning, release process, and the shape of the project

The version number is the first thing to read. The current version is 0.0.59, and the release list shows v0.0.59 on 2026-10-11, v0.0.58 on 2026-09-26 and v0.0.57 on 2026-08-25. A project at 0.0.x is telling you that the interface and the behaviour are still moving, and for an application whose whole surface is a keyboard-driven overlay, that means a keybinding you rely on today may change.

The cadence is roughly every two to three weeks, which is a fast release rate for a desktop application and indicates an active single-maintainer project. The repository is not archived, and the last push was on 2026-10-18, a week after the v0.0.59 tag.

There is a RELEASE_PROCESS.md at the top level, and that is the file to read if you want to understand how a release is put together, including the signing and notarisation steps that the macOS artefacts need. There is also a CHANGELOG.md, a CONTRIBUTING.md with its own guidelines, an AGENTS.md at the top level, and an assets/ directory holding the static images used in the README and the store listings. The.github/ directory holds the workflows, and the appId is dmytro.vasin.drawpen, which is the identifier your desktop will associate with the installed application.

The MIT licence is one of the more permissive, so there is no copyleft obligation on anyone who wants to use, modify or redistribute the application, and the LICENSE file at the root is the text that governs it. This is worth contrasting with the category in general, where annotation and whiteboard tools frequently ship under a proprietary or non-commercial licence, since the drawing tools here are all open source libraries with permissive terms, perfect-freehand and lazy-brush among them, and the whole application can be rebuilt from source with the scripts in package.json.

Editorial conclusion

Adopt DrawPen if you want to sketch over a shared screen during a call or a demo, and you want the same tool on macOS, Windows and Linux without buying a licence. Do not adopt it if you need annotation to work reliably on Wayland desktops, since the README documents a segmentation fault at startup with only a workaround, or if you need features the project has not built. Verify first that your Linux session starts the app without the segmentation fault, falling back to drawpen --ozone-platform=x11 if it does, that your Node version satisfies the >=22.22 <23 engine requirement if you build from source, and that the drawing surface behaves the way your presentation setup needs.

Frequently asked questions

Official sources

1. DmytroVasin/DrawPen on GitHub
2. License: MIT
3. Project website
4. README
5. Releases