TizuMark is a Windows-only Markdown editor with a split preview and a 7MB installer

The package description says cross-platform, the platform table says Windows

The repository description calls TizuMark a cross-platform lightweight Markdown editor, and the platform table that follows the download heading is narrower. Windows is marked supported. macOS and Linux are both marked as planned. The architecture note repeats it, saying a Windows version is released while macOS and Linux versions are in planning.

That gap is worth naming before anyone plans a study group or a shared machine rollout around it. The reason for the single-platform shape is visible in the architecture: Tauri v2 renders through the system native WebView, so a build inherits whatever WebView the target operating system ships, and the installer size, quoted at about 7MB with memory under 50MB, follows from not bundling a browser engine the way an Electron application would.

Downloads come from two places, the GitHub releases page and a Gitee releases mirror. No package manager route is documented, no `winget` entry, no snap, no flatpak, and the source build is a manual npm and Tauri sequence rather than a published package. The project also ships `update-windows-x86_64.json` at the repository root, which is the shape of a Tauri update manifest, and the release notes live in `RELEASE_NOTES.md` alongside an English copy.

The preview is a second pane, not a second window

TizuMark positions itself as a free Typora alternative for Windows, and the central design choice is how the preview appears. Editing happens on the left, rendering on the right, and the two scroll in sync. The project argues for this in its own comparison table, listing split-screen as a pain point where source and rendering each occupy a screen and you move between windows to read a document.

The view adapts to what you opened. Markdown files get the split preview. Plain text and code files get a single editing pane with no preview column, and image files open in a read-only preview with drag-to-pan and wheel zoom. That is a per-file-type decision rather than a global mode switch, and it is the reason opening a `.json` file does not leave an empty right-hand column.

What the pane carries is more than rendered text. Code blocks are highlighted across 100 or more languages. Emoji shortcodes such as `:rocket:` render. Task list checkboxes in the preview are clickable. The image viewer handles pan and zoom, and images get width and height attributes so they display at a sensible size. Find and replace works in the preview with regular expressions, and results can be copied out as HTML. For a document with a heading structure, the outline parses the levels automatically and jumps to any section, which is the feature that matters on a long technical note where scrolling back is the expensive part.

CodeMirror in a WebView, and two Markdown parsers in the tree

The architecture diagram splits the application in two. The frontend runs in a WebView with CodeMirror 5 for editing, highlight.js for code colouring, KaTeX for mathematics, Mermaid for diagrams and html2canvas for image capture. The backend is Rust, with Tauri 2.5, the pulldown-cmark parser, file I/O and the system dialogs. The two halves talk over IPC channels named `ipc:` and `tauri:`.

`package.json` complicates that tidy picture. Alongside the diagram, the JavaScript dependencies carry `markdown-it` and a full remark and rehype chain: `remark-parse`, `remark-gfm`, `remark-rehype`, `rehype-raw`, `rehype-sanitize`, `rehype-stringify` and `unified`. So the tree holds a Rust Markdown parser and a JavaScript one, and the documentation does not say which of the two produces the preview you read. Readers planning to extend the renderer need to resolve that in the source rather than from the diagram.

Two other dependency names explain behaviour you would otherwise have to guess at. `rehype-raw` followed by `rehype-sanitize` is the standard pairing for accepting raw HTML in a document and then sanitising it before display, which is what stops a pasted script tag from running in the preview. `mathml2omml` and the `docx` and `html-docx-js` packages are the Word export path. The `prepare` script runs a renderer build and a vendor check, and `check` runs a globals check, a coupling report, a version check and two test files, which is the shape of a repository that checks its own seams on every run.

Building from source, where the clone step and the cd step disagree

The documented build sequence is short, and it has one rough edge:

git clone https://github.com/tizuio/TizuMark-Markdown-Editor.git
# 或国内镜像：
git clone https://gitee.com/tizu/TizuMark-Markdown-Editor.git
cd tizu-mark
npm install
npm run dev      # 开发模式
npm run build    # 构建发布版本

Git names the directory it creates after the repository, so a clone of `TizuMark-Markdown-Editor.git` produces `TizuMark-Markdown-Editor`, while the line after it changes into `tizu-mark`. On a case-insensitive Windows filesystem the name still differs, so the sequence as printed needs the directory name adjusted before it runs. The Gitee mirror exists for networks where GitHub is slow, and it clones the same project under the same repository name.

`npm run dev` builds the renderer and then starts Tauri in development mode, and `npm run build` does the same against a release build. A `postbuild` hook then copies the compiled executable to a versioned name built from the `version` field in `package.json`, which is currently 1.2.4, so a release artifact ends up carrying its own number rather than a generic one. The npm scripts also include `build-frontend` and `test`, and the `postbuild` step is guarded by an existence check on `src-tauri/target/release/tizumark.exe`.

Word export converts formulas and diagrams into pictures

TizuMark exports to four formats and they are not equivalent in what survives. Single-file HTML carries complete styling and works with no network at all, which is the one to reach for when a document has to be sent to someone. High-resolution long PNG goes through html2canvas. PDF comes out of the system print dialog rather than a built-in renderer, so the output depends on the printer drivers installed on the machine. All of them keep the dark or light theme styling.

The Word path is the weak one, and the documentation is direct about it. DOCX export turns formulas and diagrams into images, and scales images proportionally so they do not break out of the page. A KaTeX expression that renders perfectly on screen arrives in Word as a picture of that expression. You can read it, you cannot edit it, and you cannot restyle it. The same holds for a Mermaid flowchart, which also carries the ELK auto-layout engine in the preview and follows the light and dark theme colours, none of which survives as vector content in the DOCX.

Two smaller limits sit alongside. The image paste feature stores pictures either in an assets directory or inline as Base64, deduplicating by MD5, and it accepts Obsidian style embeds such as `![[图片路径]]` with an optional `|600` size suffix, so relative paths resolve the same way in the preview and in the export. The dependency on `rehype-sanitize` is worth keeping in mind for any document that mixes prose with pasted HTML.

Virtual rendering and a prompt when the file changes underneath

Documents with tens of thousands of lines are handled by a sliding window and virtual rendering, so only the region being read is turned into elements. The stated effect is that the editor stays responsive on very large files, which is a different claim from saying the file opens fast, and no timings for either appear in the documentation.

The other half of large-document work is what happens when the file is not only yours. TizuMark watches for external changes on disk and prompts to reload rather than overwriting silently. In a folder workspace with a repository checked out, that is the difference between a collaborator's commit landing cleanly and a work session ending with the working tree quietly reverted to what the editor last saw.

Around that sit the smaller things that decide whether an editor stays open all day. Tabs can be reordered by dragging, files open in batches, and a folder workspace gives a sidebar file tree. `Ctrl+H` searches across files, `Ctrl+P` jumps by filename or path, and a recent files list is kept. Unsaved state is marked and closing prompts before discarding. There is a status bar with a running word count, a system tray icon that can be hidden, a choice of what closing the window does, and a global hotkey to bring the window back. A session restores the tabs, the folder workspace and the expanded directories after a restart. Shortcuts are all remappable under `文件 → 快捷键设置`, with a restore-defaults button in the same place.

One maintainer, GPL-3.0, and a document the project cannot answer

The repository describes itself as one person's open-source work, and it asks for donations through Alipay and WeChat codes in the readme. Version 1.2.4 was published on 2026-09-30, the same day as the last push to the default branch, with 1.2.3 on 2026-09-09 and 1.2.2 on 2026-08-29, so the release cadence is weeks rather than months. The licence is GPL-3.0, which carries copyleft obligations for anyone who distributes a modified build.

On the question of how it compares to Typora or MarkText, the documentation offers a positioning line and nothing more. TizuMark calls itself a free Typora alternative and contrasts itself with heavy tools and bare notepads, but there is no comparison test, no feature matrix against either named editor, and no statement about import compatibility. Typora's own approach and MarkText's differ from a synced split pane, and nothing in the repository describes either of them well enough to arbitrate.

What the documentation does answer is narrower and useful. TizuMark is free and open source with no limit on the basic features. It opens seven Markdown extensions, 20 image formats, and plain text and code files. Defaults can be restored from `文件 → 设置` and from the shortcut panel. Support runs through a QQ group, Gitee issues and GitHub issues. What is not documented is a plugin API, a custom theme format, or a headless mode, and the readme is a project overview rather than a manual, so the deeper settings live in the interface itself.

Editorial conclusion

Adopt TizuMark on Windows if you write Markdown with formulas and Mermaid diagrams daily and want a small installer with an offline single-file HTML export, and accept that exports to Word arrive as images. Do not adopt it if you need macOS or Linux today, or if the split pane gets in the way of a single-window writing view. Before installing, open the release page and confirm that the newest build matches what you need, since the platform table lists macOS and Linux as planned and the Word path is the one export where the output is not editable.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. tizuio/TizuMark-Markdown-Editor on GitHub