zenfmt vs md2rich: Zig Markdown Converter Compared 2026

A new open-source converter landed on Hacker News on August 17, 2026. zenfmt (insanai.github.io/zenfmt) is a document-to-Markdown tool written in Zig and compiled to WebAssembly so the whole engine runs in your browser. It supports 19 input formats, ships a CLI and an HTTP server, and ships benchmark numbers that claim it is roughly 6.9x faster than AnyDoc and 31x faster than a warm Apache Tika server on the same corpus.

The natural question for anyone already using md2rich is whether zenfmt overlaps with the daily publishing workflow. It does not. zenfmt is the inbound step that turns messy office files into a Markdown draft. md2rich is the outbound step that turns a clean Markdown draft into the platform-specific rich text your destination accepts on paste. Together they form a closed-loop client-side publishing pipeline. This breakdown covers what each tool does, where they converge, and which one to reach for in August 2026.

What zenfmt offers

zenfmt is the open-source project page at insanai.github.io/zenfmt, and the project's own description frames it as a small attempt to explore the pandoc idea with a faster, smaller engine. The headline stat from the homepage is the benchmark table: native CLI ratios of 6.9x faster than AnyDoc on wall time, 7.9x more efficient on CPU time, and 10.1x lower on peak memory, all geometric means across the 14 files AnyDoc and zenfmt both convert. Against a long-running Apache Tika Server, the ratios widen to 31.1x on latency and 34.2x on peak memory, with a throughput of 552.7 documents per second at a single client versus Tika's 4.4.

The format list spans the formats a typical office worker actually touches: Word (.docx), Excel (.xlsx), PowerPoint (.pptx), OpenDocument (.odt, .ods, .odp), EPUB, RTF, and PDF, plus a handful of markup and data formats. The engine detects the source format from the file contents rather than the extension, which matters when a file has been renamed or downloaded without one. The browser UI exposes a drop zone, an Advanced options panel with three loss policies (Convert and report loss, Refuse content loss, Refuse structural loss, Refuse any known loss, Preserve facet details), and a read-only Markdown output area with Copy, Download, and Wrap lines actions.

# zenfmt CLI (single binary, no Java or Python bundle)

# Browser path - runs entirely in the tab
zenfmt-web
  drop DOCX, EPUB, PDF, or any of 19 formats
  engine: Zig compiled to WebAssembly
  output: clean Markdown (copy/download)
  privacy: nothing uploaded

# Local HTTP server (optional, loopback by default)
zenfmt serve
  opens on 127.0.0.1:8998
  --secure mode adds users, keys, audit log
  curl -s -T report.docx "http://127.0.0.1:8998/api/v1/convert?to=markdown"

# Distribution
  1 file CLI, 7 native targets (Linux/macOS/Windows)
  no bundled Java, Python, OCR, VLM, or model assets

Where md2rich specializes

md2rich is narrower by design. It accepts one input format — Markdown — and produces one family of output: the rich text that publishing platforms accept on paste. The reason for the narrow scope is that the conversion output matters more than the format list when your goal is to publish. A Markdown-to-LinkedIn conversion that drops bold formatting on paste is useless even if it handled 18 other format pairs correctly. md2rich has spent two years tuning its output against each platform's paste handler.

The tuning list, learned through iterative testing: LinkedIn strips <span> tags with inline styles but respects <strong> and <em> when they are direct children of <p>. X Articles collapses nested lists past two levels but keeps a clean trailing-paragraph structure. Notion converts pasted HTML to native blocks and reads <h1> through <h3> as headings, but ignores <h4> and below. Medium reinterprets <h2> as a full-width separator and ignores <h3>. Substack preserves inline <code> but strips classes on <pre> blocks unless they are coded as <pre><code> with no class attribute.

zenfmt produces clean HTML from Markdown, and that HTML works on most platforms most of the time. But zenfmt is not tuned for platform-specific paste behavior — its goal is fidelity to the source document, not fidelity to the destination platform. md2rich's output is tuned for the platforms where the edge cases waste your morning.

Head-to-head comparison

The combined pipeline

The pattern that fits zenfmt and md2rich together is the same pattern that worked for earlier client-side converters: a two-step pipeline where each tool handles the half it is designed for.

1. Step 1 — Inbound. You receive a client brief as a DOCX file, a meeting transcript as a PDF, or a competitor analysis as a PPTX export. Open zenfmt in the browser, drop the file in, and get clean Markdown out. zenfmt detects the source format from the bytes, runs the Zig engine in WASM, and renders the Markdown in the read-only output area. No upload, no server, no conversion fee.
2. Step 2 — Edit. Take the Markdown into your editor of choice (Obsidian, VS Code, iA Writer — all the tools covered in our 2026 editor roundup). zenfmt does not edit; it converts. Spend three or four revision passes tightening the draft.
3. Step 3 — Outbound. When the draft is final, open md2rich, paste the Markdown, and copy the platform-optimized rich text to your clipboard. md2rich converts Markdown into the specific HTML structure each platform's paste handler accepts.
4. Step 4 — Publish. Cmd/Ctrl-V into LinkedIn, X Articles, Notion, Medium, or Substack. Headings render correctly, bullets stay indented, code blocks survive the paste, links are clickable. The format travels intact because the conversion was tuned for that destination.

The pipeline is fully client-side. zenfmt handles the inbound many-to-Markdown step with a Zig engine in your browser. md2rich handles the outbound Markdown-to-publish step with JavaScript in your browser. Nothing touches a server between the source file and the published post.

# Combined pipeline (one real example)

# 1. Source is a 1.2MB DOCX client brief
#    Open zenfmt in the browser, drop the file in
#    zenfmt → 4.8KB clean Markdown (DOCX detected from bytes)

# 2. Edit the draft in VS Code (3-4 revision passes)

# 3. Open md2rich.com, paste final Markdown
#    md2rich → platform-tuned rich text

# 4. Cmd+V into LinkedIn post composer
#    Headings render as LinkedIn H2, bullets stay indented,
#    code blocks survive, links are clickable.

What zenfmt changes in 2026

zenfmt's Show HN pitch is that the document-conversion space has been waiting for a smaller, faster engine than what Java and Python bundles ship. The project's release notes point out that zenfmt does not bundle Java, Python, OCR, VLM, or model assets — the binary is one file, and the same engine runs in the browser as WebAssembly and on the command line as a native binary. That combination was not practical in 2022 because the Zig toolchain and the WebAssembly ecosystem both needed another two years to mature.

The benchmark against AnyDoc and Tika is what makes the project's claim concrete. AnyDoc is a JavaScript-based universal converter that runs in roughly the same form factor zenfmt targets — in a browser or Node.js — and zenfmt's reference run shows a 6.9x wall-time advantage across 14 shared files. Against Tika Server, which is the long-standing reference for batch office-document conversion on a JVM, zenfmt's 31.1x latency advantage and 552.7 documents-per-second throughput at one client make a strong case that the format-conversion bottleneck in many publishing pipelines has been the runtime, not the conversion logic.

For md2rich's audience — multi-platform writers who edit in Markdown and publish on LinkedIn, X Articles, Notion, Medium, and Substack — the relevant change is that the inbound step is now faster and lighter. Converting a 1MB DOCX in the browser without uploading it to a third party used to mean a slow WebAssembly converter or a desktop pandoc install. zenfmt delivers both modes from one Zig codebase, which makes the inbound step portable across machines and operating systems.

Where zenfmt still lags

zenfmt is at version 0.3.5 and the project page is honest about the gaps. The browser engine needs JavaScript enabled because the conversion runs in the browser rather than on a server, and the converter rejects content that would lose structural information when round-tripped. The web app exposes four loss policies in the Advanced options panel — Convert and report loss, Refuse content loss, Refuse structural loss, Refuse any known loss, and Preserve facet details — but the strictest of those means some conversions will return a refusal instead of a partial output.

DOCX-to-Markdown handles paragraphs, bold, italic, and headers cleanly. Tables are converted but complex merged-cell layouts are flattened. Images embedded in DOCX files are referenced but not extracted as inline media in all cases. PDF-to-Markdown is the weaker path — text extraction is reliable, but multi-column layouts are concatenated, inline images are dropped, and table positioning is approximated rather than reconstructed. For a PDF that was designed in a WYSIWYG tool, the Markdown output will need manual cleanup.

The CLI/server path has its own caveats. zenfmt serve opens on 127.0.0.1 by default, which means the server is reachable only from the host machine. The --secure mode adds users, API keys, an audit log, and a small admin interface, but it does not turn the local server into a public endpoint. If your workflow needs a shared conversion service for a team, you would need to put zenfmt behind a reverse proxy with its own authentication layer — the project does not ship a hosted multi-user mode.

Which tool wins when

The decision matrix is straightforward:

• Use zenfmt when your source is a file in DOCX, XLSX, PPTX, ODT, EPUB, RTF, PDF, or any of the other formats zenfmt parses. It is the fastest way to bring an external document into the Markdown ecosystem without uploading it to a server.
• Use md2rich when you have a finished Markdown draft and need to publish it on LinkedIn, X Articles, Notion, Medium, or Substack with full formatting preservation. md2rich produces output tuned for each platform's paste handler.
• Use both in sequence when your workflow starts with a non-Markdown file and ends with a published social or long-form post. zenfmt handles the inbound DOCX/EPUB/PPTX-to-Markdown step; md2rich handles the outbound Markdown-to-publish step. Nothing touches a server.
• Neither tool helps when you need server-side batch conversion of thousands of files per hour (run pandoc on a server instead), or when your destination platform does not accept HTML on paste (rare in 2026 but worth checking for new platforms).

There is no meaningful overlap. zenfmt brings content into the Markdown ecosystem. md2rich takes it out. The two tools handle opposite ends of the same one-person publishing pipeline, and neither replaces the other.

The 2026 client-side conversion landscape

zenfmt is the fourth significant entrant in the privacy-first Markdown conversion category in 2026. md2rich covers the publishing-specific outbound conversion. all2md covers the Python/CLI/MCP path for developer workflows. PrivateMarkdown covers the browser-based 135-format path for non-technical writers. zenfmt covers the Zig/WASM browser path for writers who want a single small engine that also runs locally as a CLI and an HTTP service.

The broader trend in 2026 is that serverless conversion is becoming the default expectation. Users who would have uploaded a DOCX to a cloud converter in 2024 now search for browser-based alternatives. The WASM ecosystem matured enough in 2025-2026 to make format parsers in the browser practical, and zenfmt's 6.9x speed advantage over AnyDoc on the same WASM-style architecture suggests the gap between "works in the browser" and "fast in the browser" is closing quickly.

For the writer whose workflow is: receive a file in DOCX/PDF/EPUB/PPTX, convert to Markdown, edit, publish to social platforms, the logical stack in mid-August 2026 is zenfmt + your editor of choice + md2rich. It runs entirely in your browser, requires no accounts, and does not expose your content to a server at any step in the chain. The combined pipeline is fully client-side and faster than the cloud converters it replaced.

FAQ