Markdown apps often get compared as if they solve the same problem. They do not. Marked 2 is a companion previewer. Typora is a focused live-rendered editor. Obsidian wraps Markdown files in a knowledge base. Zettlr aims to be an entire research and publication workbench.
I installed current builds of all four in the same clean macOS 26.6 ARM virtual machine and gave them the same document. I tested what I could observe and verify: installation trust, first-run experience, common Markdown rendering, GUI editing, saving to ordinary .md files, restart speed, application size, and process memory.
No product received a hand-tuned theme or plugin advantage. Every app saw the same headings, emphasis, blockquote, task list, table, code fence, and plain-text file structure.
The short answer
| If you want… | Pick |
|---|---|
| A separate preview beside your existing editor | Marked 2 |
| The cleanest all-in-one Markdown editor | Typora |
| A local-file knowledge base with linking and plugins | Obsidian |
| A research-heavy publication environment | Zettlr |
Typora was the lightest app in this test. Marked 2 was the strongest pure preview workflow. Obsidian made the most sense once the document became part of a vault. Zettlr exposed the most built-in workspace machinery, at the cost of the busiest interface and largest measured memory footprint.
What I tested
The installed versions were:
- Marked 2 2.6.45
- Typora 1.14.9
- Obsidian 1.13.4
- Zettlr 4.7.0
All four bundles passed macOS Gatekeeper assessment as notarized Developer ID applications. Each application was opened normally, brought frontmost, and tested through visible GUI interaction. A save only counted as a pass when the unique token typed through the app also appeared in the underlying Markdown file on disk.
The performance numbers below are observations from this VM, not universal benchmarks. “Restart to front” is a warm restart after each app had already been launched once. Memory was summed across processes whose executable path belonged to that app, two seconds after launch.
Results at a glance
| Product | Warm restart to front | App bundle | Process memory | Render | GUI edit/save | Notable first-run friction |
|---|---|---|---|---|---|---|
| Marked 2 | 247 ms | 43.8 MiB | 200.4 MiB | Pass | Preview-only; live refresh passed | Tutorial, trial, and update prompts |
| Typora | 283 ms | 45.5 MiB | 116.4 MiB | Pass | Pass | Initial document shell briefly appeared blank |
| Obsidian | 280 ms | 514.4 MiB | 528.8 MiB | Pass | Pass | 14.6-second first launch and mandatory vault choice |
| Zettlr | 235 ms | 532.1 MiB | 741.6 MiB | Pass | Pass | Setup wizard plus an unnecessary microphone request |
The warm restart timings are too close to matter in practice. The footprint spread is not: Typora used roughly one-sixth of Zettlr's measured process memory, while Marked 2 and Typora occupied less than one-tenth of the disk space used by Obsidian or Zettlr.
Marked 2: best when you already like your editor
Marked 2 watches a Markdown file while another app edits it. That separation is the entire appeal: the source stays plain text, your editor stays your editor, and Marked becomes a dedicated reading, review, and export surface.
The common fixture rendered headings, emphasis, inline code, tasks, and a table correctly. I then replaced the open source file outside Marked. Within two seconds, the preview rebuilt without a manual reload.
That live-refresh result is the strongest single behavior in this comparison because it validates Marked's central promise. Its weakness appeared before the work began: a multi-page tutorial was followed by trial and update dialogs stacked over the rendered document. Once dismissed, the interface was quiet and direct.
Marked 2 is the right answer if you write in Vim, BBEdit, VS Code, or another tool you do not want to replace. It is the wrong answer if you expect the preview window itself to be your main editor.
Typora: the cleanest writing surface
Typora removes the split between source and preview. Its official description calls this a “real live preview”: Markdown syntax recedes while the structure remains editable in place. The test supported that description. Headings, tasks, inline code, tables, and the code fence all became a coherent document rather than a source pane beside a rendered pane.
Typora successfully persisted TYPORA_SAVE_OK to the plain Markdown file. Its navigation semantics were the only small surprise: both Command-End and Command-Down, after clicking in the document, placed the insertion before the task list rather than at the physical end of the source file. The edit itself remained a valid standalone paragraph and saved correctly, but keyboard-oriented writers should test navigation against their own habits.
Typora was the lightest application here: about 45.5 MiB installed and 116.4 MiB of measured process memory. It also reached frontmost in 1.0 seconds on its first launch, much faster than Obsidian's initial setup path. The unregistered badge is visible during the trial, but it did not block the document.
Choose Typora when the document is the product and you want the least interface between you and it.
Obsidian: Markdown as a knowledge system
Obsidian would not treat an arbitrary file as the whole experience. It first asked for a vault, so I opened the fixture directory as a local vault and selected the document from the file list. That added friction—14.6 seconds from first launch to frontmost in this run—but also explains the product: Obsidian organizes relationships among files, not just one document.
Its default Live Preview rendered the fixture correctly. The official view documentation explains that Live Preview hides most syntax until the cursor enters formatted content and that Command-E switches between editing and reading views.
The GUI-entered OBSIDIAN_SAVE_OK token persisted to the Markdown file. Obsidian also showed an 80-word, 623-character status readout after the edit. Tasks appeared with purple controls and completed text received a strike-through, making state more visually emphatic than in the other apps.
The cost is footprint and ceremony: roughly 514 MiB installed and 529 MiB of measured process memory. That overhead buys a vault model, backlinks, extensibility, and a broader knowledge workflow. It is difficult to justify for previewing one file, but easy to justify when links among hundreds of files are the point.
Zettlr: the publication workbench
Zettlr opened with a setup wizard, a tutorial workspace, multiple tabs, and a three-pane split-view demonstration. It then requested microphone access even though this Markdown test required no audio. I denied the request; the editor continued to work normally.
After onboarding, Zettlr rendered the shared document correctly and saved ZETTLR_SAVE_OK at the actual end of the file. Its task boxes, tables, code highlighting, word count, character count, cursor position, and preview status were all visible without adding plugins.
The density is intentional. Zettlr's editor documentation describes a Markdown environment with tables, footnotes, linting, autocompletion, YAML front matter, scientific tools, and export workflows. Its official feature comparison emphasizes citations, projects, writing statistics, split views, and Pandoc-compatible export.
The trade-off was the largest resource footprint in this test: about 532 MiB installed and 742 MiB across its processes. Zettlr makes more sense as an office for a thesis, paper, or book than as a lightweight viewer for a README.
Rendering and file portability
All four applications passed the common rendering checks. More importantly, the three editors wrote back to normal Markdown files, and their unique tokens were verified at the byte level after saving.
| Capability | Marked 2 | Typora | Obsidian | Zettlr |
|---|---|---|---|---|
| Headings and emphasis | Pass | Pass | Pass | Pass |
| Task-list rendering | Pass | Pass | Pass | Pass |
| Inline/fenced code | Pass | Pass | Pass | Pass |
| Table rendering | Pass | Pass | Pass | Pass |
Save GUI edit to .md
|
Not its role | Pass | Pass | Pass |
| Follow external file changes | Pass, verified | Not tested | Not tested | Not tested |
| Requires a project/vault | No | No | Yes | No, but workspace-oriented |
I did not test PDF fidelity, Word export, mathematics, citations, community plugins, custom themes, or thousand-file projects. Those are substantial workflows deserving dedicated fixtures rather than superficial checkmarks.
Which one should you install?
Use Marked 2 if you already have an editor you love and want a purpose-built live preview, review, and export companion. Its automatic file watching worked exactly as advertised.
Use Typora if you want the shortest path from opening a file to writing in a polished view. It had the smallest memory footprint, the smallest bundle alongside Marked 2, and the least conceptual overhead.
Use Obsidian if Markdown is the storage layer for a personal knowledge system. For one document it feels oversized; for a network of notes, the vault requirement becomes the feature rather than the obstacle.
Use Zettlr if your work involves research, citations, long manuscripts, or publication pipelines. Its interface and footprint are heavy, but so is its built-in ambition.
There is no universal winner because these tools optimize different units of work: Marked 2 optimizes the preview, Typora the document, Obsidian the knowledge graph, and Zettlr the publication project. The best choice follows from deciding which of those is actually yours.
Top comments (0)