# docu.md Markdown Viewer for diagrams and Word exports

> docu.md Markdown Viewer is a TypeScript project that opens Markdown files in the browser and exports them as Word documents with editable math, highlighted code, and multiple diagram formats. Its broad platform support and local-processing model come with substantial release and packaging complexity.

**markdown-viewer/markdown-viewer-extension** — Markdown to perfect Word in one click — Mermaid, Vega, drawio, canvas, Infographic, Graphviz, LaTeX (editable), code highlighting, local processing

- Repository: https://github.com/markdown-viewer/markdown-viewer-extension
- Stars: 1,897 · Forks: 153
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/markdown-viewer-markdown-viewer-extension

## docu.md's technical-document export problem

docu.md targets a specific gap between ordinary Markdown preview and business-ready Word output. Its package description says it opens Markdown files in the browser and exports polished Word documents with diagrams, editable math, code highlighting, and local processing. The intended users are therefore people who prepare technical documentation, specifications, reports, or educational material in Markdown but still need a Word document as a deliverable.

The repository layout shows that this is not a single browser extension. It contains platform directories for Chrome, Edge, Firefox, VS Code, Obsidian, and mobile applications. It also includes a Slidev shell, an HTML CLI named `documd`, shared source code, test directories, and numerous Markdown demonstration files. That scope matches a document pipeline designed to preserve complex technical content across several publishing environments.

Its advertised content coverage is unusually broad. The project description names Mermaid, Vega, draw.io, Canvas, Infographic, Graphviz, and LaTeX as editable or exportable elements, depending on the feature. Demo files provide concrete examples such as `demo/demo.mermaid`, `demo/demo.vega`, `demo/demo.drawio`, `demo/demo.canvas`, and `demo/demo.infographic`. There is no generic claim that every Markdown construct will translate perfectly to Word. The practical value lies in handling document features that commonly survive poorly in a basic Markdown preview.

## Shared rendering across browsers, editors, and mobile

The repository is organized as a shared implementation with platform-specific packaging. The root `src/` directory is accompanied by `chrome/`, `edge/`, `firefox/`, `vscode/`, `obsidian/`, and `mobile/`. Platform build scripts collect or package the shared capabilities for their respective environments. This layout suggests a common rendering core rather than separate implementations of Markdown conversion for every target.

The data flow implied by the demos begins with a Markdown document containing ordinary prose plus embedded blocks for diagrams, math, charts, raw HTML, and specialized formats. The renderer interprets those blocks in the browser or host environment, while the Word export path produces a document rather than only a visual preview. The description specifically calls the LaTeX output editable, while code highlighting is included as an export feature. These details matter because static screenshots would not provide editable equations or reusable code presentation.

Slidev extends the pipeline beyond ordinary document conversion. The release documentation says that some platform builds can continue with a warning when a Slidev asset is absent, then ship without Slidev support. The VS Code build depends on both `npm run build:slidev` and `npx tsx slidev-shell/build-themes.ts`. The Obsidian build reads files produced by the VS Code build. Mobile packaging also expects Slidev output in `dist/`.

This dependency chain is the clearest architectural constraint in the release documentation. A complete desktop or mobile package may require intermediate artifacts that are not obvious from its final installer name. Consumers who need Slidev should therefore verify the packaged webview files, not merely assume that every successful build includes that feature.

## Platform artifacts and local-first installation choices

The available documentation does not provide a user installation procedure, a browser extension URL, or a supported `npm install` command for the HTML CLI. It does identify where software is distributed: GitHub Releases built by `release.yml`. Because no official homepage or store procedure is provided, the article cannot responsibly invent an installation command.

A release contains a distinct artifact for each supported destination. The listed files include `chrome-v<version>.zip`, `edge-v<version>.zip`, `firefox-v<version>.zip`, `vscode-v<version>.vsix`, `obsidian-v<version>.zip`, `documd-cli-v<version>.tgz`, and Android APK or AAB files. Obsidian also receives `main.js`, `manifest.json`, and `styles.css` through a separate bare-version release. Consumers should choose the archive that matches their browser, editor, plugin host, or mobile platform rather than assuming that one universal build exists.

For maintainers, the documented release procedure starts by changing the `version` field in `package.json`. The build scripts copy that value into the Chrome, Edge, Firefox, Obsidian, mobile, and VS Code manifests. The documented tag command is:

```bash
git tag v5.4.0 && git push origin v5.4.0
```

This example reflects the release instructions rather than the current package version, which is `5.3.2`. The tag must match `v` plus the `package.json` version. The workflow stops in its `prepare` job when that rule is not met.

The repository exposes a first-use route for contributors through its validation command:

```bash
docker run --rm -v "$PWD:/repo" --workdir /repo rhysd/actionlint:latest
```

The README says this validates the local GitHub Actions workflow. It is not a document export or end-user installation step.

## Word output scope and format-specific constraints

docu.md is most useful when the source document depends on technical formats beyond Markdown headings, lists, and code fences. Demo files include Mermaid, Vega-Lite, ECharts, draw.io, Graphviz, Canvas, Infographic, OpenAPI YAML, HTML, and math-oriented content. The top-level description also names LaTeX as editable. These formats cover several ways authors express relationships, workflows, data visualizations, and equations.

Local processing is a central product choice. The package description says Markdown rendering and Word export happen locally. That makes the project relevant to users who do not want document content sent to a remote conversion service for every operation, although the available documentation does not describe telemetry, network requests, or the full privacy implementation. `PRIVACY.md` exists in the repository, but its contents are not included in the available documentation.

The claim that output can be “perfect” belongs to the repository description rather than to a documented conversion guarantee. Word compatibility for complex diagrams and layout remains a practical constraint. The repository includes `demo/docx-spacing-test.md`, which indicates attention to DOCX spacing, but the file does not provide results or supported rendering thresholds. It would also be incorrect to infer that Canvas or draw.io objects become fully native editable Word shapes. The documentation confirms format support, but it does not specify the editability level of every diagram type.

Users should therefore judge suitability against their own documents. A technical report centered on Mermaid, highlighted code, and editable LaTeX fits the advertised feature set. A layout-critical brochure with many arbitrary HTML constructs or manually placed objects requires comparison with the actual exported file.

## Release failures from missing Slidev artifacts

The clearest documented failure mode is a platform build that warns about missing Slidev assets and still produces a package. The release documentation calls these builds that “fail silently if assets are missing.” In practical terms, the installer can exist while one feature family is absent. Checking only that a build exited successfully would miss this condition.

The dependency order is explicit. Run `npm run build:slidev` and the theme build before `npm run build:vscode`. The Obsidian package then consumes `dist/vscode/webview/slidev-shell-inline.html` and `slidev-theme-bundles.json`, so it requires the VS Code build first. The mobile build requires `dist/slidev-shell-vscode` and `dist/themes`. `release.yml` is said to build and assert these assets in its artifacts, but local packaging outside that workflow does not receive an equivalent guarantee unless the contributor follows the same order.

This design creates an upgrade cost. Platform maintainers must understand not only the final build command but also inherited intermediate files and theme bundles. A contributor changing the VS Code package can indirectly alter what Obsidian receives. A contributor changing Slidev output can affect mobile artifacts as well. Shared code reduces duplication across platforms, but it also increases the number of build paths that need verification.

For organizations standardizing on one platform, that cost may still be acceptable. Teams distributing several targets should add artifact inspection to their release checklist, particularly when Slidev is part of the expected user experience.

## Mobile signing, licensing, and maintenance boundaries

Android release readiness depends on secrets that are not part of the normal repository configuration. Without them, `node mobile/build-app.js android` produces a debug-signed APK that can be side-loaded but is rejected by the Play Store, while the AAB is skipped. Play Store artifacts require `ANDROID_KEYSTORE_BASE64`, `ANDROID_KEYSTORE_PASSWORD`, `ANDROID_KEY_ALIAS`, and `ANDROID_KEY_PASSWORD`. The documented alias value is `markdown_viewer`.

iOS and macOS builds have a different boundary. The workflow does not automate them because they require a macOS runner plus Apple certificates and provisioning profiles. Store submissions are also manual for Chrome Web Store, Edge Add-ons, AMO, VS Code Marketplace, Open VSX, npm, Play Store, and App Store. Building an artifact therefore does not mean it has been submitted or approved for every destination.

The repository is not archived, and the last push was on 2026-10-14. Recent releases include v5.3.2 on 2026-09-25 and v5.3.1 on 2026-09-22. The repository record therefore indicates recent repository activity, but it does not guarantee compatibility with every browser, editor, or store.

The project uses GPL-3.0. Users distributing modified or combined versions need to account for the license obligations that apply to their use. This is a licensing boundary, not legal advice. The documentation also includes `PRIVACY.md`, but its contents are not available for a claim about data collection or retention.

## docu.md versus a minimal Markdown previewer

A minimal Markdown previewer can render text in an editor without creating a large cross-platform release graph. docu.md takes a different approach: it shares a document-rendering and export implementation across browser extensions, editor integrations, Obsidian, mobile builds, and an HTML CLI. Its added scope supports technical formats such as Mermaid, Vega, Graphviz, LaTeX, Canvas, draw.io, and Infographic, but it also introduces platform packaging, asset ordering, signing, and store-distribution work.

This comparison is about approach rather than a named competitor. A simple viewer is the better fit when the required output is limited to Markdown preview, portability matters more than Word export, and maintainers do not want to manage browser manifests, VSIX packaging, Obsidian bundles, APK signing, or Apple signing. docu.md is the better fit when local conversion and rich technical content justify that packaging model.

For maintainers, the release workflow also has a useful safety property. Releases begin as drafts and become visible only after all build jobs succeed. Re-running `release.yml` uploads replacement assets with `gh release upload --clobber`. However, prerelease tags such as `v5.4.0-beta.1` deliberately skip the bare-version Obsidian release, so beta users do not receive that update through Obsidian.

The decision should therefore be based on document requirements first and release scope second. A team that needs Word output with diagrams and local processing can justify docu.md's complexity. A team that only needs to read Markdown should prefer a smaller preview-only project.

## Conclusion

Technical writers and developers should consider docu.md Markdown Viewer when browser-based Markdown editing, local processing, and diagram-rich Word exports matter more than a minimal extension. Teams that need repeatable distribution should first verify the selected platform artifact, especially Slidev assets and Android signing. Projects seeking a simple Markdown viewer without complex cross-platform builds should choose a lighter tool.

## FAQ

### How do I install docu.md Markdown Viewer?

The available documentation does not give an end-user installation command or extension URL. It states that GitHub Releases contain platform-specific archives, including Chrome, Edge, Firefox, VS Code, Obsidian, CLI, and Android artifacts.

### Can docu.md export Mermaid, Vega, and LaTeX to Word?

The repository description names Mermaid, Vega, and editable LaTeX among its supported export features. The available documentation does not define the exact Word editability of every diagram format.

### Does docu.md send Markdown files to a server for conversion?

The package description identifies local processing as a feature. The available documentation does not describe network requests, telemetry, or retention behavior, and the contents of `PRIVACY.md` are not included.

### Why can a docu.md build succeed without Slidev support?

Some platform build scripts warn and continue when Slidev assets are absent. The release workflow builds and asserts those assets, while local builds need the documented Slidev, theme, VS Code, and mobile dependency order.

### What is required to publish the Android app to the Play Store?

Without repository secrets, the Android build produces a debug-signed APK and skips the AAB. Play Store artifacts require `ANDROID_KEYSTORE_BASE64`, `ANDROID_KEYSTORE_PASSWORD`, `ANDROID_KEY_ALIAS`, and `ANDROID_KEY_PASSWORD`; store submission remains manual.

## Sources

- [Issues](https://github.com/markdown-viewer/markdown-viewer-extension/issues)
- [License: GPL-3.0](https://github.com/markdown-viewer/markdown-viewer-extension/blob/main/LICENSE)
- [markdown-viewer/markdown-viewer-extension on GitHub](https://github.com/markdown-viewer/markdown-viewer-extension)
- [README](https://github.com/markdown-viewer/markdown-viewer-extension/blob/main/README.md)
- [Releases](https://github.com/markdown-viewer/markdown-viewer-extension/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/markdown-viewer-markdown-viewer-extension