Launched this week
MD+HTML Reader
Review AI-generated Markdown and HTML in a focused workspace
119 followers
Review AI-generated Markdown and HTML in a focused workspace
119 followers
AI coding tools produce useful docs, but reviewing them can get messy. One task can leave plans, API notes, QA checklists, handoffs, diagrams, and HTML previews scattered across project folders and buried under source files, builds, logs, and dependencies. MD+HTML Reader gives you a focused macOS workspace to review generated Markdown and HTML in read-only mode before the next prompt, commit, or handoff.
Free Options
Launch Team / Built With
MD+HTML Reader
AI coding tools generate a surprising amount of documentation now, but reviewing it is still pretty fragmented. Curious what percentage of your users are reviewing AI-generated docs versus human-written project documentation?The "before the next prompt, commit, or handoff" framing is interesting. In your own workflow, what type of AI-generated document caused the most pain and ultimately led you to build MD+HTML Reader?
MD+HTML Reader
@yagnaveena Thank you for the thoughtful question. I really appreciate it.
I do not have enough user data yet to answer the percentage question honestly. My current belief is that AI-generated docs are making an existing documentation problem more visible. Project docs were already scattered before, but AI coding tools can now create more review material much faster.
The most painful case for me was reviewing the Markdown docs around one task: implementation plans, API contracts, QA checklists, handoff notes, and similar files spread across different folders. The review step became fragmented because the related context was not in one place.
Another workflow I personally find very useful is reviewing documentation from the project level. Opening the whole project folder helps me see the documentation layer of a project more clearly, instead of only looking at whichever file I happen to open next.
So the product is intentionally not an editor. It is a small read-only workspace for reviewing that documentation context before deciding the next action.
The read-only review step after an agent generates docs is the part I'd actually use — I keep opening plan.md in my editor and half-editing it out of reflex. The thing I'd test first: when it renders the HTML previews, does it sandbox them to static rendering, or do embedded <script> tags and remote asset references actually execute inside the workspace? For agent-generated HTML I'd want to be sure nothing runs before I've read it.
MD+HTML Reader
@hi_i_am_mimo That’s a good point. Today MD+HTML Reader treats an HTML artifact more like a local browser preview than a static HTML sanitizer.
The main reason is rendering fidelity: a lot of generated HTML reports, slide decks, prototypes, and visual artifacts depend on CSS or JavaScript to display correctly. If the app blocked all scripts by default, some previews would look broken or misleading compared with what the file actually represents.
That said, the boundary should be clear. The current preview runs in a sandboxed frame inside the app, uses a no-referrer policy, and opens links externally. But it is not a “nothing executes” static mode: scripts may run, and remote assets may be requested by the underlying WebView.
I do think adding a stricter Safe Preview mode would be valuable. That way the browser-like preview can still serve normal HTML artifacts that need accurate rendering, while users reviewing unknown agent-generated HTML can switch to a more restricted mode for that safety-sensitive case.
I’ll add this setting in the next couple of days. Thanks a lot for the thoughtful suggestion, and I’d really appreciate it if you take a deeper look at MD+HTML Reader and share more feedback from actual use.
That's a fair tradeoff for fidelity — a no-execute mode would break exactly the decks and prototypes people want to preview. What I'd reach for is an opt-in strict toggle for untrusted artifacts: scripts off and no remote asset fetch, so I can open something sketchy without the WebView reaching out, then flip full rendering back on for stuff I trust. Is a per-file or per-session toggle like that on the table?
MD+HTML Reader
@hi_i_am_mimo Thanks for making the feature boundary so concrete. I agree with this direction, and your framing is very helpful — it separates the normal fidelity case from the untrusted-review case much more clearly.
I’ll add a global Strict Preview toggle for untrusted HTML artifacts: scripts off and remote asset loading blocked by default. For files that need full rendering, users will be able to switch that individual file back to full preview, and the app will remember that choice.
I’ll let you know once there’s an update. Thank you again.
MD+HTML Reader
@hi_i_am_mimo Quick update: this is now shipped. You can wait for the app to prompt for the update automatically, or manually trigger “Check for Updates.”
MD+HTML Reader now has a global Strict Preview toggle for untrusted HTML artifacts. When it’s on, HTML previews run with scripts disabled and remote asset loading blocked. If a specific file needs full rendering, you can switch that file back to full preview, and the app remembers both the global setting and the per-file choice.
Thanks again for the very clear suggestion. It directly shaped the implementation.
This is the exact mess I deal with after a Claude Code session, plans and handoff notes end up scattered across folders and I end up grepping just to find what changed. Curious how it detects "recently changed" docs, is it watching file mtime, or does it diff against Git so it knows what actually changed vs just got touched?
MD+HTML Reader
@liam_appbuildchat Good distinction. Right now it’s based on filesystem modified time from the folders you open, not Git diff.
That means it works for non-Git folders, uncommitted agent output, and handoff notes that haven’t been added to a repo yet. The tradeoff is that a file that only got touched can still show up as “recently modified.”
A Git-aware view is a good next step though: keep mtime for universal recency, and optionally add a Git-based filter/status so you can tell what actually changed versus what was only touched.
I’d really appreciate you exploring the app more. If you have any further thoughts on this workflow, I’m happy to discuss them and will actively turn useful suggestions into product features and ship them quickly.
Congrats on the launch! Any plans to launch it for other platforms? (like Linux)
MD+HTML Reader
@ashishkingdom Thanks a lot! I’m starting with macOS because that is where my own workflow is today, and I want to make the local folder review experience reliable before expanding. The macOS app already supports auto-updates, so users can automatically keep getting future improvements.
Linux/Windows are very interesting to me too. If there is demand, I’d be very happy to build and provide versions for those systems. If Linux or Windows would be useful for your workflow, I’d love to know which platform matters most to you.
@ahabwang personally speaking, its Linux (Ubuntu) for me.
MD+HTML Reader
@ashishkingdom Got it. I’ll start trying this soon and will let you know once there is progress. I’d be grateful if you keep following along.
What's the real benefit over markdownlivepreview.com?
MD+HTML Reader
@sakshamgarg Totally fair question. I think Markdown Live Preview is great if you want to paste or edit a single Markdown note in the browser and see it render immediately.
MD+HTML Reader is aimed at a different workflow: reviewing files that already live in a local project folder, especially the Markdown and HTML artifacts generated by AI coding tools. It filters a project folder down to readable Markdown/HTML, keeps the review read-only, supports rendered Markdown/Mermaid plus local HTML preview, keeps recent viewed/modified docs close, and does not upload document contents.
So I wouldn’t frame it as a replacement. If your job is quick Markdown editing, Markdown Live Preview may be the simpler fit. If your job is checking a pile of generated plans, reports, diagrams, and HTML artifacts across a repo before the next prompt, commit, or handoff, that’s the gap MD+HTML Reader is trying to cover.
Thanks for taking a look. I’d be happy if you give MD+HTML Reader a deeper try, and I’d really appreciate any feedback or suggestions from your actual use.
I can definitely relate to the problem. After using AI coding tools, I often end up with plans, docs, and notes spread across multiple folders. Having a dedicated space just for reviewing Markdown and HTML before moving forward sounds really useful.
MD+HTML Reader
@sousadiego11 Thank you, that is exactly the workflow I built MD+HTML Reader for.
MD+HTML Reader gives the AI-generated doc review step its own focused workspace, so the “review before commit, next prompt, or handoff” moment becomes calmer and easier to trust.
Beyond that, I also added features that help in day-to-day review work: quickly returning to recently viewed or recently changed documents, and browsing by document title when filenames are unclear. You can see more concrete examples near the end of the video.
There are also features that are not shown in the video, such as outline preview, collapse/expand, quick positioning, and keyboard shortcuts. They are all designed to make AI agent workflows easier to review and manage. I’d be very happy for you to try it and share any feedback.