MarkerOn: a 1.5 MB screen annotation tool where click-through is the point

The session model, in three steps

MarkerOn is a lightweight screen annotation tool, around 1.5 MB, and it describes itself as keyboard-first: press a hotkey to instantly draw, highlight and annotate anywhere on your desktop.

The workflow is three steps, and the shape of it is what makes the tool pleasant.

First, install and launch. MarkerOn runs in the system tray, and no window appears. Second, enter annotation mode by pressing Ctrl + Shift + D, or Command + Shift + D on macOS. Third, draw and then click through, using the number keys and V for Select to pick tools, pressing X to interact with the apps below while keeping the annotations visible, and Esc to exit.

The third step is the interesting one and the reason to use this rather than a screenshot tool. A typical annotation overlay swallows clicks, so the moment you want to demonstrate the thing you just circled, you have to dismiss the overlay, and the annotation you made is gone or the overlay flickers. MarkerOn's click-through mode lets the clicks pass to the application underneath while the marks stay on screen, so you can circle a button and then click the button.

There is a second mode as well. Whiteboard mode lets you set the default entry to whiteboard, or press W to toggle, and its content rules live in the Whiteboard and content settings. The whiteboard copy action copies the whiteboard as an image with Ctrl or Command + C.

For people new to the tool, the documentation points at one thing first: press Space for the toolbar.

Eleven tools and a keyboard mapping you can learn in a minute

The tool set is eleven items, and every one of them is bound to a key that does not move between contexts.

The mapping is V for Select, 1 for Pen, 2 for Highlighter, 3 for Arrow, 4 for Rectangle, 5 for Ellipse, 6 for Line, 7 for Eraser, 8 for Laser, T for Text and N for Stamp.

The fact that the numbers are grouped by shape type rather than by frequency is a small design decision that pays off. Pen, highlighter and arrow are the three you use constantly and they are 1, 2 and 3, and the geometric shapes follow in the order you would reach for them, and then the rarer ones, text and stamp, get letter keys. The letters never conflict with the numbers, so a muscle memory for the number row and a separate one for the letters coexist without either getting in the way.

There are three global shortcuts as well. Toggle annotation mode is Ctrl + Shift + D, clear all annotations is Ctrl + Shift + C, and toggle click-through mode is Ctrl + Shift + X. On macOS, Command takes the place of Ctrl and Option takes the place of Alt throughout.

The most interesting binding is the one that is not global. Pressing X while drawing switches to click-through for that session, and there is a separate global Ctrl + Shift + X. The distinction matters, because the local version is an in-the-moment action while you are annotating and the global one is a mode switch, and mixing those up is the kind of thing that would make the tool feel unpredictable.

Other common actions include Delete or Backspace to delete a selection, and pressing 7 again while the eraser is selected to cycle eraser mode between stroke and object.

The claim in the feature list is that there is full keyboard control, every action has a shortcut, no menus needed. For a tool you use while talking to other people, that is the difference between it working and not working, because hunting for a toolbar with a mouse while an audience waits is a visible cost.

Click-through has three entry points and one exception

Click-through mode is worth a section of its own, because it is the feature that justifies the tool existing and it has a specific behaviour.

It can be reached three ways. The toolbar has buttons for it, the global shortcut is Ctrl + Shift + X, and pressing X while drawing switches to it for the current session. The point of having both a global and a local binding is that one is for the mode you are already in and the other is for when you have not started drawing yet.

The exception is whiteboard mode, where click-through is disabled. That is correct rather than a limitation, because in whiteboard mode there is no application underneath to click through to. The whiteboard is the content, not an overlay on something else.

Around that sits a set of related behaviours that make the session usable rather than a demo. The flexible toolbar is toggled with Space, or can be enabled as always-on in Settings. It is a compact panel with an Expand view for full options, undo, copy and whiteboard actions, and it can be an independent floating window with its own drawing and click-through toggles.

The marquee batch edit is what you use when you have made a mess. Press V for Select and you get box select and click select, group drag, and Delete to remove a selection, which is the difference between correcting one arrow and clearing twenty.

There is also a preserve-drawings option, Keep after exit, under Whiteboard and content, so a session can be resumed on re-entry. That is the feature that turns the tool from a transient overlay into a workspace, and for a teaching session that spans several slides it is the one you would miss first if it were missing.

Rust and Vue on Tauri, with a version-pinned toolchain

The stack explains the size, and the repository layout shows it.

The application is built with Tauri, with a Vue 3 and TypeScript frontend under `src/` and a Rust side under `src-tauri/`. The feature list describes it as Rust plus Canvas with minimal memory, and the topics list includes both tauri and vue3, tailwindcss, vite and typescript.

That combination is what produces the 1.5 MB installer. A Tauri application ships the system web view rather than bundling a browser engine, so the binary is a small native executable with the frontend assets inside it rather than a runtime plus a framework. The cost of that choice is that the frontend renders in whatever web view the operating system provides, so the styling has to live with the differences between WebView2 on Windows and WebKit on macOS.

The build tooling is pinned hard. The `engines` field in the package manifest requires node 24.15.0 and npm 11.12.1, and the package manager is npm 11.12.1, with a `.node-version` and `.nvmrc` file in the repository. There is even a `preinstall` script that runs `node scripts/check-node.mjs`, so an install on the wrong Node version fails immediately rather than midway through.

The scripts show a project that takes its release process seriously. There are separate build targets for macOS ARM64 with `tauri build --target aarch64-apple-darwin`, for a signed build with a dedicated tauri sign configuration, for an MSIX package and for a portable zip, each with a shell script, and a `build:all` that chains them. The release process itself is a script, `node scripts/release.mjs`, with a `release:check` mode.

Testing is split between vitest for the frontend and the Node test runner for the scripts, and linting uses oxlint rather than the more common eslint. The formatting is prettier, and there is a commitlint configuration with czg for commit messages, plus husky hooks wired through a `prepare` script.

Distribution, and the caution about mirrors

Downloads are offered as a Windows x64 installer, a macOS ARM64 build, a macOS x64 build, and a Microsoft Store listing, all through GitHub Releases.

Windows also ships a portable zip, marked with a `*_x64_portable.zip` suffix, and the distinction from the installer is stated plainly: extract and run, and the config stays under `data\` next to the exe, with no AppData. That is a meaningful difference for anyone running the tool from a USB stick or on a locked down machine where writing to the user profile is not allowed.

The Microsoft Store version is also installable with WinGet:

winget install --id 9N6623X973JV --source msstore

The documentation adds a warning that official downloads are GitHub Releases and Microsoft Store, and that third-party mirrors may be outdated or repackaged. For a tool that draws over your screen and runs in the background, that warning is worth taking seriously, because a repackaged binary is the shape of thing you would not notice.

The repository layout backs the release story. There is a `packaging/` directory, an `appxmanifest.xml` for the Microsoft Store package, a `promo/` directory for the store listing material, a `PRIVACY.md` and a `SECURITY.md`. The feature list also states that MarkerOn runs quietly in the system tray with no extra daemons or telemetry, which is the kind of claim worth making explicit for a background application.

There is a Chinese README linked at the top, a Chinese Bilibili tutorial badge, and a sponsor link to Afdian, and the release script even has a `sync:sponsors` task, which tells you the project runs a small sponsorship programme alongside the open source work.

Where a dedicated annotation tool stops making sense

The honest case for this tool is narrow, and the alternatives cover a lot of the same ground for free.

The first alternative is the annotation feature your operating system or meeting software already has. Most screen sharing tools and most presentation software can draw on the screen while you talk. If you are already in a meeting on a platform with a built-in annotation toolbar, a separate desktop app duplicates that and adds a hotkey collision risk, because MarkerOn's global shortcuts are Ctrl + Shift + D, C and X, which are not exotic enough to be free on every keyboard layout.

The second alternative is a screenshot tool with a delay, which covers the case of annotating something you just showed. Most of those tools have a shape, an arrow and a text box. What they do not have is click-through, because a screenshot overlay is a separate window, and if you draw on top of a live application and then need to interact with the application, you need the overlay to pass clicks through. That is the specific gap MarkerOn fills.

The third is a full whiteboard application, which is what whiteboard mode is for. If your work is teaching a diagram rather than pointing at a live interface, a whiteboard with proper shapes and export is the better tool, and MarkerOn's whiteboard is deliberately simple.

The platform limit is the other boundary. The downloads cover Windows x64, macOS ARM64 and macOS x64, so there is no Linux build, which is a shame given that the project is open source and a Tauri port would not be a large lift, but it is not there today.

The last thing to weigh is the size claim itself. Around 1.5 MB is genuinely small compared with the Electron equivalents, and it is the direct consequence of shipping the system web view. The trade is that the app inherits the system web view's behaviour, which means a rendering difference between Windows and macOS is your problem to handle rather than a runtime you control.

On maintenance, the project is current. The last push was on 2026-10-08 and version 2.11.1 was released the same day, with 2.10.5 and 2.11.0 both on 2026-09-29, which suggests a tight release cadence. The licence is MIT.

Editorial conclusion

MarkerOn fits a person who annotates while presenting or teaching, because click-through mode lets you operate the application underneath while the marks stay on screen, and because every action is a shortcut so nothing depends on finding a cursor. Skip it if your work is on Linux, since the downloads cover Windows x64, macOS ARM64 and macOS x64 only, and skip it if you need screen recording as well, since it annotates during screen recording rather than recording the screen itself. Before you install, note that official downloads are GitHub Releases and the Microsoft Store, and that the Windows portable zip keeps its config next to the executable rather than in AppData. The last push was on 2026-10-08 with v2.11.1 released the same day.

Frequently asked questions

Official sources

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