Moji: an Electron Markdown reader and editor that opens .md files like documents

The problem Moji addresses: Markdown files that behave like documents

Most Markdown tooling assumes you are either writing source in a code editor or publishing through a static site generator. Neither is a good fit when someone hands you a .md file and you want to read it the way you would read a PDF: open it, scroll, click a heading in an outline, then export it to something you can send to someone else. Moji is aimed at that workflow. The README describes it as "a lightweight, clean desktop app for opening, reading, editing, and exporting Markdown files", and the repository is a TypeScript Electron application with React, CodeMirror 6 and Mermaid among its topics.

The target user is someone who receives Markdown rather than authors a repository of it. A technical writer reviewing a draft, an engineer reading a design doc, or anyone who wants to export a README to PDF without opening a terminal. The feature list reflects that: file association entry points, drag and drop, a Welcome screen with recent files, and an About panel. It is not positioned as a replacement for an IDE.

How Moji works: Electron main process, sandboxed renderer and a Web Worker parser

The architecture is a standard Electron split with specific choices that matter for large files. The main process reads files and streams them in UTF-8 chunks, and the renderer decodes incrementally. Markdown parsing and syntax highlighting run in a Web Worker, so the UI thread is not the one doing the parsing. For documents above 20 MB, the README states that the preview switches to block virtualization so only the visible part stays in the DOM. That is the mechanism behind the large-document claim, and it is the part of the design worth understanding before you throw a 50 MB file at it.

Security is configured the way Electron documentation recommends: sandboxed renderer, context isolation, nodeIntegration set to false, DOMPurify sanitization of rendered Markdown, and external links opened in the OS browser. Local images referenced relative to a document are served through an authorized moji-asset:// protocol restricted to directories of documents you actually opened, loaded lazily and cached in memory. That restriction is the interesting part: it means an image path pointing outside the directories you have opened will not resolve, which is a deliberate boundary rather than a bug.

The editor is CodeMirror 6 with line numbers, history, wrapping and Markdown formatting shortcuts. Live preview is a resizable split view toggled from the top bar or with Ctrl+\, and scrolling either pane moves the other to the matching part of the document. The README notes the toggle is disabled in view mode and when the workspace is too narrow for two readable panes, which is a sensible refusal rather than a squashed layout.

Installing Moji and opening your first Markdown file

The README points at prebuilt artifacts for v1.0.7: a Windows installer (Moji.Setup.1.0.7.exe), a macOS universal DMG (Moji-1.0.7-universal.dmg), a Linux AppImage (Moji-1.0.7-x86_64.AppImage) and a Debian package (Moji-1.0.7-amd64.deb). There is no package manager command in the README, so installation means downloading the artifact for your platform from the releases page.

Building from source is documented through the package.json scripts. The engines field requires Node ^20.19.0 or >=22.12.0, and there is a postinstall step that installs the Electron binary.

npm install
npm run dev

npm run dev launches the app through electron-vite. After it starts, the Welcome screen lists recently opened files. Dragging a .md file onto the window opens it in a tab, and the README also lists file dialog, CLI/file association entry points and single-instance forwarding as ways in.

Once a document is open, the two modes worth trying first are Preview and Editor. Preview renders sanitized Markdown with heading anchors, tables, task lists, footnotes, LaTeX math via KaTeX, and copy buttons on code blocks. Editor mode gives you the CodeMirror source view. Pressing Ctrl+\ toggles the split live preview, which is the fastest way to see how the two panes stay in sync.

To produce a shareable file, use Export mode on the active document. The README lists HTML, PDF and PNG as targets, with PDF supporting A4, Letter, Legal, portrait and landscape. Long code lines wrap in PDF and PNG exports, and exports report their current phase and can be cancelled.

Where Moji is the wrong tool

Moji is a single-user local application. The README documents no plugin API, no extension marketplace and no collaboration features, so if your team edits Markdown in a shared repository with review workflows, Moji will not participate in that beyond writing files to disk. It is also not a terminal tool: there is no CLI documented for rendering a file to stdout or converting a directory of Markdown in a batch, which rules it out for CI pipelines and static site builds.

The asset protocol boundary is a real constraint. Because moji-asset:// is restricted to directories of documents you actually opened, a document that references images via absolute paths or paths outside its own directory tree may not display them. The README does not document a fallback or a setting to widen that scope, so if your Markdown corpus uses a shared image directory outside the document folders, verify rendering before committing to the app.

The 20 MB threshold is another boundary. Block virtualization applies above that size, and the README does not state what happens to search, outline scroll-spy or export behaviour on documents that large. If you routinely handle very large generated Markdown, treat that as unverified.

Finally, update checks are limited. The README says installed Windows NSIS and Linux AppImage builds check GitHub Releases and link to the release page when a newer version is available. macOS is not listed, and the check links out rather than updating in place, so you remain responsible for installing the new version.

Moji compared with a general-purpose code editor

The obvious alternative is VS Code with a Markdown preview extension. The difference is in defaults rather than capability. VS Code is a code editor that can preview Markdown; Moji is a document viewer that can edit Markdown. In VS Code you open a folder as a workspace, the preview is a side panel, and Mermaid rendering depends on which extensions you have installed. In Moji, Mermaid is bundled: the README states that every valid fenced mermaid block supported by bundled Mermaid renders as a responsive diagram, including flowcharts, sequence, Gantt, class, ER, state and journey diagrams, and that malformed Mermaid blocks remain readable code blocks rather than breaking the preview.

Export is the sharper difference. VS Code has no built-in PDF or PNG export for Markdown. Moji's Export mode produces HTML, PDF or PNG from the active document, embeds rendered Mermaid diagrams as self-contained SVG, and reports export progress with a cancel action. If your workflow ends with sending someone a PDF, that is the gap Moji fills.

The trade-off runs the other way too. VS Code has an extension ecosystem, integrated terminals, Git integration and remote development. Moji has none of that, and the README does not suggest it intends to. Pick based on whether the Markdown file is the artifact you care about or a file inside a larger project.

Maintenance, licence and the cost of keeping Moji current

The repository is not archived, and the last push was on 2026-09-11, six days before this writing. Releases v1.0.6 and v1.0.7 landed on 2026-08-22 and 2026-09-10 respectively, so the release cadence over that window is roughly one release every two to three weeks. That is a reasonable pace for a single-author desktop application, though it also means the project's continuity depends on one maintainer, which the package.json author field and the About view both point to.

Moji is MIT licensed. For most users that means you can use, modify and redistribute it, including in commercial settings, provided the licence notice is preserved. The repository ships a LICENSE file at the top level. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, read the LICENSE file and your own obligations rather than relying on this summary.

The upgrade cost is low by design. There is no server component, no database and no migration path to worry about. User settings (window size and position, recent files, last used folder, language, preview typography, font sizes, reading width, preview theme, split ratio and untitled-document recovery preference) are persisted locally, and the README does not describe a settings schema version or migration step. The practical risk of upgrading is a settings key changing meaning between versions, which you would notice immediately rather than through data loss. On Windows and Linux AppImage you will be told a newer version exists; on macOS you check the releases page yourself.

Editorial conclusion

Adopt Moji if you want a desktop application that treats Markdown files as documents to open, read and export, with tabs, an outline, split live preview and Mermaid rendering, and you are comfortable installing a signed-format binary or building from source with Node 20.19 or 22.12 and newer. Do not adopt it if you need a terminal editor, a plugin ecosystem, or a web-hosted collaborative editor; Moji is a local single-user application with no plugin API in the README. Before relying on it, verify two things yourself: that your document opens correctly through the moji-asset:// protocol when images sit outside the opened document's directory, and that the export formats you need (HTML, PDF, PNG) behave as expected on your own files, because the README describes the export phases but does not document a rollback for a cancelled export beyond stating that no partial file is left behind.

Frequently asked questions

Official sources

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