Full width home advertisement

IT Sharing

Travel the world

Climb the mountains

Post Page Advertisement [Top]

 Markdown Visual - an markdown viewer, markdown editor, side by side edit

markdown viewer



TLTR you can visit the site and download Markdown Visual here   https://markdown.io.vn/

I work with Markdown files almost every day.

README files. Technical notes. Architecture documents. AI-generated output. Specs. Random .md files sitting somewhere inside a project folder.

Most of the time, I am not trying to work on a Markdown project.

I just want to open a file and read it.

That sounds like a very small problem.

Until you do it twenty times a day.

I only wanted a quick Markdown view

My original workflow was simple: double-click a .md file and use a lightweight Markdown viewer.

It worked.

But it also had a few small annoyances that kept adding up.

Some viewers treat every Markdown file as an isolated document. If I open README.md and then want to check architecture.md sitting next to it, I have to go back to Explorer and open another file.

If I spot something that needs changing, I often have to switch to another editor.

And one thing that bothered me more than it probably should: advertising inside a simple document viewer.

Ads are understandable in free software. But when I am screen-sharing during a technical discussion or opening documentation while presenting something, having a large ad suddenly appear next to the document is not exactly the experience I want.

So I started thinking:

What would the Markdown viewer I actually want to use look like?

Not another IDE.

Not another knowledge-management platform.

Not another cloud note-taking system.

Just a really good way to open, browse, search, edit and preview Markdown files.

That became Markdown Visual.


Quick View first

The most important feature is still the simplest one.

Double-click a Markdown file.

It opens as a rendered document.

That is it.

I call this Quick View because that is how I use Markdown most of the time.

I don't want to see the raw syntax:

## Architecture

**Important:** this service requires...

When what I really want to read is:

Architecture

Important: this service requires...

Source code is great when I am editing.

Rendered Markdown is much better when I am reading.

A dedicated Markdown viewer should understand that distinction.


One file usually belongs to a folder

The next problem was navigation.

Markdown rarely exists alone.

A folder may look like this:

docs/
├── README.md
├── architecture.md
├── deployment.md
├── api.md
└── troubleshooting.md

If I open architecture.md, there is a good chance the next file I need is already sitting beside it.

So Markdown Visual automatically treats the surrounding folder as a lightweight workspace.

Open one Markdown file and the other Markdown files nearby become available in the sidebar.

No importing.

No creating a vault.

No project configuration.

No database.

Just the folder you already have.

This turned out to be one of my favorite parts of the app because it makes Markdown documentation feel connected without trying to turn Markdown Visual into a full IDE.


Multiple files, tabs and history

Once folder navigation existed, opening only one file at a time stopped making sense.

So I added tabs.

Now I can keep a README, an architecture document and a deployment note open at the same time and move between them without constantly reopening files.

There is also recent-file history, which sounds boring until you realize how often you think:

Where was that .md file I opened yesterday?

Small feature.

Surprisingly useful.


Then Quick View needed an Edit button

At some point I would inevitably find something like:

teh service requires...

Now I had another decision to make.

Should Markdown Visual remain a pure viewer?

I decided no.

If I am already looking at the document, fixing one line should not require launching another application.

So Markdown Visual has three modes:

Preview for reading.

Editor for writing.

And the one I personally use the most:

Split View.

Markdown source on the left.

Rendered result on the right.

Type here:

## Deployment

The service runs on SAP BTP.

And immediately see the rendered result beside it.

No save-refresh-preview loop.

No switching windows.

Just edit and see the result.

Live preview is a common feature in Markdown editors for a reason: once you get used to writing beside the rendered document, going back to editing Markdown blind feels unnecessarily slow.


Search the workspace, not just the current file

This feature came later, but it quickly became one of the most useful.

Imagine a documentation folder with fifty Markdown files.

I remember writing something about:

OAuth callback

But I have absolutely no idea which file contains it.

Ctrl+F is not enough because I do not know which file to open first.

So I added Quick Content Search directly to the toolbar.

Type:

OAuth callback

And Markdown Visual searches the Markdown files in the current workspace.

Results show the file and surrounding context.

Click one and jump directly there.

For technical documentation, generated notes and larger project folders, this is much more useful than treating every .md file as an island.

And because the workflow is local-first, the search happens against the files on the machine rather than requiring a cloud document index.


Markdown help without opening another browser tab

I know Markdown pretty well.

I still forget table syntax.

Every. Single. Time. 😅

So there is also a Markdown Help panel inside the app.

Need a table?

A task list?

A fenced code block?

A link?

Open Help, find the syntax, copy or insert it.

The editor also supports Markdown-oriented snippets, so common structures do not require memorizing everything.

Again, none of this is revolutionary.

That is kind of the point.

These are small pieces of friction that disappear when the tool understands the workflow.


I deliberately did not build another IDE

This was probably the most important product decision.

Once you have file navigation, tabs, search, an editor, and syntax highlighting, it becomes very tempting to keep going.

Add Git.

Add a terminal.

Add extensions.

Add AI.

Add databases.

Add collaboration.

And suddenly the “small Markdown viewer” has fourteen panels.

There are already excellent tools for that.

I wanted Markdown Visual to stay focused on a much narrower workflow:

Open. Browse. Search. Edit. Preview.

That's it.

If I need a full development environment, I already have one.

Markdown Visual should be the thing I use when opening a Markdown file does not justify launching one.


Local-first was also the obvious model

Markdown is already portable.

A .md file is just a file.

I didn't want the application to require users to move their documents into some special workspace format before they could use it.

The files remain normal Markdown files in normal folders.

That also makes the app useful for the kinds of files developers already have everywhere:

README.md
CLAUDE.md
AGENTS.md
architecture.md
plan.md
notes.md
release.md

Especially now that coding agents and AI tools generate more Markdown than ever, I find myself opening these files constantly.

The file format did not need reinventing.

The viewing workflow just needed to be nicer.


Building it

Under the hood I went with Tauri + Rust + React.

I wanted a desktop architecture that could stay reasonably lightweight while still giving me proper filesystem integration and room to extend beyond Windows.

The direction is desktop-first:

Windows
macOS
Linux

With the architecture intentionally kept portable enough that mobile platforms can be explored later.

A lot more engineering went into things users hopefully never think about:

  • File associations and single-instance behavior.
  • Filesystem watching and external file changes.
  • Safe saves and large Markdown files.
  • Workspace scanning and search cancellation.
  • Keeping typing responsive during live preview.
  • Platform differences.

That work is less exciting to screenshot.

But it is usually the difference between a demo and something I am comfortable using every day.


What started as a tool for myself became Markdown Visual

The funny part is that I never originally planned this as a “product”.

I was solving my own workflow.

I wanted to double-click a Markdown file and immediately read it.

Then I wanted the other files beside it.

Then tabs.

Then editing.

Then live preview.

Then search.

And somewhere along the way it became something worth packaging properly.

Markdown Visual is simply my take on a focused desktop Markdown workflow.

A tool for the moments when you think:

I just want to open this .md file.

And then maybe edit it.

And maybe find another one.

Without turning that small task into a whole workflow.


Try Markdown Visual

If you work with Markdown regularly, check out the current builds and supported platforms here:

Download Markdown Visual

More information:

markdown.io.vn

I am continuing to improve it based on the things I actually run into while using it day to day.

Sometimes the best side projects don't start with:

“What product should I build?”

They start with:

“Why does this tiny thing keep annoying me?”

And then Codex gets a very long blueprint. 😄


Made with ❤️ by Leo

#Markdown #MarkdownViewer #MarkdownEditor #MarkdownPreview #DeveloperTools #DesktopApps #Tauri #Rust #React #BuildInPublic #LocalFirst

Không có nhận xét nào:

Đăng nhận xét

Bottom Ad [Post Page]