In the era of LLMs (ChatGPT, Claude, DeepSeek) where Markdown is the universal lingua franca for documentation and agent workflows, reading and validating .md files shouldn't feel like a chore.
Yesterday, while reviewing a complex technical spec generated by Claude, I opened one of the top Google-ranked online markdown viewers. The result? A massive sticky bottom ad covered nearly 40% of my vertical workspace, and the tool insisted on refreshing the whole page.
That frustrating moment inspired me to spend the weekend building MDPreview β a zero-latency, 100% client-side, distraction-free Markdown viewer & live editor.
π‘ Core Engineering Decisions
Here is what went into the architecture:
- π 100% Client-Side Privacy: All Markdown parsing and highlighting happen strictly in your browser's local memory. No text, tokens, or documents are ever uploaded to any backend server.
- β‘ Zero-Lag Synchronized Scrolling: Built with Vite and marked.js for sub-millisecond typing response and proportional two-way split scrolling.
- π¨ Full GitHub Flavored Markdown (GFM): Native support for responsive tables, interactive task checklists, strikethroughs, footnotes, and math expressions.
- π» Syntax Highlighting for 180+ Languages: Powered by Highlight.js with automatic language badges and one-click code copy buttons.
- π Thoughtful Typography Themes: Switch easily between GitHub Light, GitHub Dark, Eye-Care Warm Sepia, and Midnight Dark.
- π€ One-Click Export: Export cleanly styled standalone HTML files or download
.mdfiles with a single click.
π Tech Stack & Open Source
- Framework: Vite + Vanilla TypeScript + Modern CSS
- Markdown & Highlight: Marked.js + Highlight.js
- Hosting: Cloudflare Pages (Edge CDN)
The full source code is public and open-source on GitHub:
π tangtang-it/mdpreview
π¬ Looking for Your Feedback!
This is an early release and I'd love to hear from fellow developers:
- What is the most annoying limitation in your current Markdown reading workflow?
- Would client-side PDF-to-Markdown or Markdown-to-Social-Card generation be more useful for the next sprint?
Check it out at https://mdpreview.dev and feel free to share your thoughts below!
Top comments (2)
Before either conversion feature, I'd prioritize an explicit offline preview mode. Local parsing and no document upload are useful boundaries, but a Markdown image URL could still make the preview contact a remote host.
A small privacy regression fixture could contain an external image, raw HTML, and an image whose URL includes a synthetic document identifier. Does preview or standalone HTML export load any of those automatically? Blocking remote assets by default, with a visible "load external images" choice, would make the privacy promise easier to understand without assuming the whole document was uploaded. I haven't tested your app; this is a case I'd want included in its tests.
nice β swapfile.live takes the same approach for file conversions, everything runs client-side so nothing leaves your browser