MarkEdit: a 4 MB native macOS Markdown editor built on CodeMirror 6

The problem MarkEdit solves: TextEdit without the Markdown tax

Most Markdown editors on macOS fall into one of a few camps. Electron apps give you features and a large download. TextKit-based editors handle ordinary documents but struggle as files grow. Editors written in Rust are fast but do not feel like macOS apps. MarkEdit's stated position is that it does not try to win any single dimension; the README says the goal is a balance across size, speed, native integration, and correctness. The target user is someone who already writes Markdown and wants a plain editor, not a publishing system. The README frames it as "just like TextEdit on Mac but dedicated to Markdown." That framing matters because it sets expectations about scope: there is no vault, no graph view, no plugin marketplace inside the app. The repository layout reflects this. MarkEditMac holds the app, CoreEditor holds the editor layer, MarkEditKit and MarkEditCore hold shared code, and MarkEditTools and QuickLookMac cover tooling and Quick Look integration. There is no server component and no sync service.

How the editor is put together: CodeMirror 6 inside a native shell

The architecture is a hybrid. Editing behavior, including multi-caret editing and code folding, is built on CodeMirror 6, which the README cites for correctness and performance. The surrounding UI is AppKit, so system behaviors stay native: force-touch word lookup, inline predictions, and Writing Tools are listed as things that work because the controls are real macOS controls. That split is the reason the app can be small and still handle large files. CodeMirror does the text work; the Swift side does windows, menus, and system integration. Customization follows the same split. The README states that customization is built around CSS, JavaScript, and CodeMirror extensions, exposed through a separate API repository, MarkEdit-app/MarkEdit-api. So the extension surface is not a proprietary plugin format. It is the editor library's own extension model, plus styling. The parsing rule is strict: MarkEdit follows the GFM specification with, in the README's words, "no proprietary syntax or invented features." If a document renders one way in MarkEdit and another way in a tool that has added its own syntax, MarkEdit is the one following the published spec.

Installing MarkEdit and editing your first file

The README gives two install paths. The manual one is to download MarkEdit.dmg from the latest release, open it, and drag MarkEdit.app into Applications. The package-manager path is Homebrew:

brew install --cask markedit

That installs the cask named markedit. MarkEdit checks for updates automatically after installation, and the README points to the releases page for version history. If you are on an older macOS release, the README links dedicated builds tagged macos-12, macos-13, and macos-14 rather than expecting the latest release to run everywhere.

For a first real use, open a Markdown file you already have and check the two behaviors the project is built around. First, typing speed on a large document: the README claims 10 MB files are edited easily, so a large README or changelog is a fair test. Second, strict GFM parsing, which you can see by opening a document that uses tables and task lists. Preview is not part of the base app. It is provided by an official extension, MarkEdit-preview, listed on the extensions page. If you want a preview pane, that is the thing to install, and the README does not document the extension's install steps beyond pointing at that page. Automation is a separate surface: the README lists Shortcuts and AppleScript integration, and points to a wiki manual for usage details rather than documenting commands inline.

Where MarkEdit is the wrong tool

The most concrete limitation is platform. MarkEdit is a macOS app. People searching for MarkEdit on Windows will not find a Windows build in this repository, and the README does not describe one. If your team is mixed-platform, this is a personal editor, not a shared standard. The second limitation is scope by design. The README links a wiki page titled "Why MarkEdit" with an anchor reading "feature-poor," and the contributing section says behavior changes should be discussed first because the app is intentionally minimal. That means feature requests that would grow the core, such as a built-in preview, a file browser, or a sync layer, run against the project's stated direction. Preview exists, but as an extension you install and keep working, not as a core pane. The third limitation is the customization model itself. CSS and JavaScript extensions are powerful, but they are code you own. There is no sandboxed theme picker described in the README, and no statement about what happens to your extensions across app updates. Anyone who wants a polished out-of-the-box writing environment with preview, themes, and export built in will spend time assembling that from parts.

MarkEdit compared with Typora, MarkText, and Obsidian

The comparison that matters is about editing model, not feature count. Typora is a WYSIWYG editor: you type Markdown and the document renders in place, so you rarely see raw syntax. MarkEdit keeps you in the source, with GFM parsing and CodeMirror's editing behavior, and shows rendered output only through the preview extension. MarkText is an Electron application, which means a much larger download and a different memory profile; MarkEdit's README makes the size contrast explicit, citing roughly 4 MB for the installer against Electron apps generally. Obsidian is a different category again. It is organized around a vault of notes, links between them, and a plugin ecosystem, so the unit of work is a knowledge base rather than a file. MarkEdit's unit of work is a file you opened, which is why it fits next to TextEdit in the mental model. None of these is strictly better. If you want rendered editing, Typora's approach is the one you want. If you want a linked note system, Obsidian is the one you want. MarkEdit competes on being small, native, fast on large files, and predictable about syntax.

Maintenance, licence, and what upgrading costs you

The repository is not archived, and the last push was on 2026-08-09, which is also the v1.34.0 release date. Before that, v1.33.1 shipped on 2026-06-30 and v1.33.0 on 2026-06-02. That is a steady release rhythm over the recent past, and the README states that the maintainers use the tool daily and keep improving it for themselves. There is no published support commitment, no LTS branch, and no stated deprecation policy for the extension API. Upgrades are handled by the app's automatic update check, with releases published on GitHub. The practical upgrade cost sits in your customizations: if you write CSS or JavaScript against MarkEdit-api, or install MarkEdit-preview or MarkEdit-theming, those are external pieces with their own repositories and release cadence, and the README does not promise API stability across versions. The licence is MIT, which is permissive and places few obligations on you beyond preserving the copyright notice and licence text when you redistribute. That is a statement about the licence identifier, not legal advice; if you plan to bundle or rebrand the app, read the LICENSE file in the repository and get your own counsel.

Editorial conclusion

Adopt MarkEdit if you write Markdown on macOS and want a small native editor that opens instantly and does not fight you over syntax. Skip it if you need Windows or Linux builds, a built-in preview pane, or a WYSIWYG surface, because none of those ship in the app itself and the preview is an official extension rather than a core feature. Before committing, verify three things on your own machine: that the release you download matches your macOS version (older builds are tagged macos-12 through macos-14, and the latest release targets newer systems), that the GFM-strict parsing accepts the syntax your existing documents use, and whether the extension you want is one you are willing to install and maintain separately.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes