KeyCastr: the macOS keystroke visualizer, and what it will not do

What KeyCastr draws, and who is recording

KeyCastr puts your typing on screen while you work. The README frames the audience directly: people making screencasts, presenting, or collaborating with others who cannot see your keyboard. Instead of a screen recording where a shortcut appears out of nowhere, the viewer sees the keys as they are pressed.

Three display modes are described: command keys only, all modified keys, or all keystrokes, plus an option to include mouse clicks. That range matters more than it sounds. A demo of a single keyboard shortcut is cleaner with command keys only, while a tutorial that walks through a terminal wants every character. The mouse click option covers the gap where a presenter clicks a menu item and the recording shows nothing.

The project has been freely available for the Mac since 2009, according to the README, and it is BSD-3-Clause licensed. It is not a screen recorder. It draws an overlay and leaves the capture to whatever tool you already use, which is why it works alongside QuickTime, OBS or a call recorder without a plugin.

How the event tap and the visualizer split apart

KeyCastr receives events from macOS. That is the mechanism named in the README, and it is why the app cannot function without permission: the operating system gates access to input events behind the Accessibility and Input Monitoring panes in Security and Privacy.

The README also states that you can develop your own visualizer on top of KeyCastr, and pull requests are welcome. That implies a separation between event capture and drawing. The shipped visualizers are the evidence: the README refers to a Default and a Svelte visualizer, and the v0.11.0 release added a Minimal visualizer, with v0.11.1 described as a refinement of its settings. Three visualizers over one capture layer is a plugin-shaped design, even though the README does not document the interface for writing one.

Network behaviour is narrow by design. The README says KeyCastr employs no networking mechanisms other than the Sparkle framework for application updates. That is the whole outbound surface as documented. There is no sync, no telemetry endpoint, no account.

The repository layout is small: top-level entries are .gitignore, .gitmodules, DEVELOPING.md, LICENSE.md, README.md, assets/ and keycastr/. The presence of .gitmodules suggests at least one dependency is pulled in as a submodule, and DEVELOPING.md is where build instructions would live, though the README itself does not reproduce them.

Installing KeyCastr and getting the first keys on screen

The README gives two install paths: download the latest release from GitHub, or use Homebrew. The cask command is the shorter one.

brew install --cask keycastr

After that, launch the app. On macOS 10.15 and newer, the README says KeyCastr appears automatically under Input Monitoring in Security and Privacy the first time you run it. Unlock the pane and check the box next to KeyCastr. On older macOS versions, or if the app does not appear there, the README says to add it manually under Accessibility using the plus button, or by dragging it in from Finder.

Position is the next thing to set. The README states the default position is the bottom left of your display, and that you move it by clicking and dragging the displayed text.

# after granting permission, restart KeyCastr when macOS prompts
# then drag the on-screen text to reposition it

What you should see is your own typing rendered in the corner of the screen as you press keys. If nothing appears, the README offers a useful diagnostic: switching from the Default visualizer to the Svelte one can help you work out whether the problem is missing event permission or a window sitting offscreen. Those are the two causes the README names for the app seeming not to work.

The README's own troubleshooting sequence is worth following in order: quit KeyCastr, remove it from any Privacy areas, start it again, accept the Keystroke Receiving dialog, enable it under Input Monitoring, then restart when macOS prompts.

The permission model is the price of admission

KeyCastr needs broad access to your input, and the README does not soften this. It states plainly that any application in the Accessibility or Input Monitoring sections is capable of receiving all your input events, and encourages you to inspect those lists, remove apps you do not believe need that access, and ask hard questions of the companies behind the software you run. That is an unusually direct paragraph for a project README, and it is accurate: the permission is not scoped to a window or an app.

On passwords, the README makes a conditional claim rather than an absolute one. KeyCastr will never receive or display your passwords, it says, so long as the website or application treats password entry as secure, for example an input element of type password or equivalent. Read that carefully. The guarantee is inherited from the target app's behaviour, not from KeyCastr's own filtering. A field that renders characters as dots but is not implemented as a secure input may not carry the same protection.

There is also a practical consequence for anyone on a managed Mac: adding an app to Input Monitoring is a security decision, and the README's instruction to remove KeyCastr from the Privacy panes and re-add it during troubleshooting is exactly the kind of change some organisations log or block.

Where KeyCastr stops: platform and scope

KeyCastr is a macOS application. The README describes macOS permission panes, macOS menu names and a Homebrew cask, and the primary language listed for the repository is Objective-C. Nothing in the README describes a Windows or Linux build, and there is no download link other than the GitHub releases page. If you searched for a Windows version, the README does not offer one; the honest answer is that the project documents itself as Mac software.

The second boundary is scope. KeyCastr visualizes input. It does not record, encode, edit or upload anything. If what you actually need is a screen recording with an input overlay, KeyCastr is one component and you still need a capture tool. If you need an audit log of what was typed on a machine, this is the wrong tool entirely: it draws keystrokes for an audience, it does not persist them for later review.

The third is the visualizer interface. The README says you can build your own visualizer and that pull requests are welcome, but it does not document an API, a plugin manifest or a template. Anyone intending to write one should read DEVELOPING.md in the repository first, since the README does not carry that detail.

Comparing KeyCastr with a general screen recorder overlay

The practical alternative is not another keystroke visualizer. It is a screen recorder that already supports a keystroke or click overlay as part of its own capture pipeline. The difference in approach is architectural. KeyCastr runs as a separate process, taps macOS input events, and draws its own floating window that your recorder then captures as ordinary pixels on the desktop. A recorder with a built-in overlay typically hooks into its own capture path and composites the input display into the video as a layer, so the overlay is not part of the desktop at all.

That distinction decides several things. With KeyCastr, whatever is on screen is what gets recorded, including the overlay window, which means you can also see it live during a presentation on a projector. With a built-in overlay, the audience in the room sees nothing and only the exported video carries the keys. KeyCastr also stays independent of the recorder, so you can switch capture tools without changing how keystrokes look. The trade-off is a second app holding Input Monitoring permission, and a floating window you have to position and keep out of the way of the content you are demonstrating.

Within KeyCastr itself, the choice is between visualizers rather than products. The v0.11.0 release notes describe the Minimal visualizer as new, and v0.11.1 as a refinement of its settings, while the README mentions Default and Svelte. If the default styling is too heavy for your recording, Minimal is the documented option.

Maintenance, licence and the cost of upgrading

The last push to the repository was on 2026-09-07, and the most recent release, v0.11.1, is dated the same day. The release before it, v0.11.0, landed on 2026-08-27, and v0.10.5 on 2025-11-24. The gap between v0.10.5 and v0.11.0 is roughly nine months, which is worth knowing if you are planning around a fix: this is a project that ships in bursts around a feature, not on a schedule. The README credits several contributors across the project's history, including the original author, and describes occasional development and maintenance on one name.

The licence is BSD 3-Clause, which is permissive and places few obligations on redistribution beyond retaining the copyright notice and licence text and not using contributor names to endorse derived products. If you fork KeyCastr to build a custom visualizer, that is the framework you are working within. Nothing here is legal advice; read LICENSE.md in the repository for the actual terms.

Upgrade cost is mostly the permission dance. The README's troubleshooting steps involve removing KeyCastr from the Privacy panes and re-adding it, and it warns that if the app is already in the list you should remove it and add it again to be certain the right copy of the application is specified. That last point is the real maintenance tax: replacing the app bundle, whether through a cask upgrade or a manual download, can leave macOS pointing at a stale entry, and the symptom is the same as a missing permission.

Editorial conclusion

Adopt KeyCastr if you record or present on macOS and need keystrokes and mouse clicks drawn on screen; brew install --cask keycastr plus an Input Monitoring checkbox is the whole setup. Do not adopt it if you need Windows or Linux, since the README names no build for either and the repository keeps its code under a single keycastr/ directory with an Objective-C codebase. Before you commit to it on a locked-down machine, verify two things: that KeyCastr appears under Input Monitoring after first launch, and that the window is not positioned offscreen, because the README lists those two conditions as the likely causes of the app appearing not to work.

Frequently asked questions

Official sources

1. Issues
2. keycastr/keycastr on GitHub
3. License: BSD-3-Clause
4. README
5. Releases