You can do this on KDE. Just set Okular as the default app for markdown files, If you want editing too LibreOffice instead (and on any OS and DE). The only problem is that it is a viewer not an editor. There are editors with preview which solve that. Even editors without preview will highlight, and, there is already software that provides exactly what the author wants (notepad, which the article mentions) or visual editing of markdown (Libre Office)

I am not sure its that important that its a default. Markdown is primarily and editable format that is easily converted to a readable one - its the inverse of PDF which is a readable format that is hard to edit.

For some reason, Okular doesn't render tables with any kind of borders. Not sure what else it's missing, but that alone has made me it a poor solution as a viewer. So I end up loading the files on the command line or in zed, which is sort of the author's point.

I never noticed this!

I've tried Okular now, and it doesn't reflow the text on width change, it just makes the font bigger/smaller (like a PDF). It also doesn't allow selecting/copying text from the file.

While I do agree with the author's overall point, I think that he inadvertently stumbles on the probable reason here:

> If I want to see the original Markdown syntax, I should be able to switch to that view just as easily.

This doesn't really map well to existing document opening conventions, so the author's hypothetical built-in Markdown viewer/editor doesn't really fit into any existing system app. For example, if Apple modified TextEdit.app to open Markdown files in the same way it handles RTF documents, it would cover the formatted display case, but not editing the source. They would have to add some third mode (or build an entirely separate app) to handle switching between Markdown source and formatted views, deal with displaying malformed syntax, etc. Not to mention handling the various differences between Markdown flavors.

It can just be a toggle button, just like 'show formatting' in lots of rich text editors. And remember the state of the last interacted window when opening a new file.

Then some sane styling defaults, which you can change globally, on a per folder and on a per document basis. Perhaps the option to include some stationary backgrounds for PDF rendering, and I think you have touched upon 95% of the document editing needs.

What would "show formatting" do in RTF? I'm guessing you don't mean show the byte codes that make text interpreted as bold (or however it's done in RTF), but then that leaves "show it as bold ... somehow". What would that look like?

It would look like

  Ham and jam and {\b Spam} a lot.

RTF, Rich Text Format, uses text tags, not "byte codes".

Obsidian has a quick shortcut to switch between view mode and edit mode, end their edit mode is actually partially formatted (# headers are displayed in a bigger font)

> Not to mention handling the various differences between Markdown flavors

Funnily enough, I was looking for Python markdown to HTML rendering library, and the author of one of the biggest two closed a bug on me reporting a minor incompatibility saying "that is GitHub format, we don't support it, we only support CommonMark, GitHub format is non-standard and broken".

Obsidian is the exact "or build an entirely separate app" that they said. It's an app just for Markdown

> edit mode is actually partially formatted

Obsidian's edit mode is 99.99% formatted. It only omits HTML symbol shorthands like "→". Other than it's completely formatted, WYISWYG as you type fashion.

Reading mode is more like a Read Only toggle on a floppy disk. Prevents accidental edits.

Obsidian has 3 modes - Reading, Live Mode, Source Mode.

I was talking about Source Mode, you seem to be talking about Live Mode, which indeed, is editable WYSIWYG

Yes, I was talking about Live Mode. I also use source mode, but not that too often.

Maybe your comment needs a little clarification?

TextEdit has become a neglected buggy mess. Apple needs to fix that before they even think of adding proper markdown support.

TextEdit already lets you switch between rich and plaintext mode, so there's a precedent. Maybe a "view without formatting" toggle in the format menu that's only enabled or visible for markdown files. The ability to open markdown documents in source view by default could be a checkbox in the Open and Save tab of the TextEdit settings window.

“MarkEdit is a free and open-source Markdown editor, for macOS. It’s just like TextEdit on Mac but dedicated to Markdown.”

https://github.com/MarkEdit-app/MarkEdit

That third mode only available when markdown is detected is the issue. I can't see Apple building in a special case at the best of times, let alone for something like markdown.

TotalCmd's Lister can handle it. By default you just get text and hex viewer, but you can install plugins (like for markdown) and then it renders rich text by default but you can switch to plain text (or hex) by pressing 1 or 3. One day I'll move away from Windows and I'll have to find a replacement :(

This essay could have been a prompt. I have a markdown viewer. Comes out of the same codebase as my json viewer https://wiki.roshangeorge.dev/w/Blog/2026-04-30/Personal_Sof...

I felt the same but if you put it into Claude code Opus 5.5 can build you a program that will open faster than anything you’ve ever used before if you ask for it. I asked for it and it’s instantaneous. Faster than literally any other macOS app.

It opens and displays a markdown file faster than bitwarden’s chrome extension displays its fill UI.

The future is almost here. Formats and so on are on the threshold of irrelevance in the next few years for this kind of consumer use. It’s hard to even tell if the time it takes us to summarize a text will be the time a future agent takes to write a specialized program that extracts what you need from the file. “Native” support will soon be irrelevant.

Even my solution is yesterday’s solution.

You completely missed the point.

The OP is arguing that something should work by default without any configuration needed, and you're talking about building a bespoke tool.

I think they're saying that the two are converging: technological advancements are making bespoke tools increasingly effortless and that paradigm shift is going to paper over a lot of pain points like this. I agree that at present, the systems are not yet accommodating, especially to people who are not technologically inclined, because things do go wrong, technical decisions are asked of the user, agents' work stalls out for X reason, etc., etc., etc.

While yes, your solution easily works it is not what the author is aiming for. If I send you a PDF you have a multitude of options on your phone already preinstalled that can open and view the PDF. Any browser does the trick at this point, easy 100% coverage across all devices. But if I send you a .md file a browser does not show the rendered content but the raw markdown which is not the expected behaviour. Markdown is so simple there is really no excuse for it to be so complicated to open what is basically just a fancy text-file. It is 2026, it should "just work", no AI needed.

> This essay could have been a prompt.

Doesn't look like this to me.

The main point of the essay is that MD files should be supported on an OS level. This way, you could share an MD file with anybody, and it will “just work”.

You could develop your own viewer, but this will not solve the problem of “just working” for every user. Because most users wouldn't install some app just to open the file you shared with them. The same way you don't expect users to install any software to open websites, images or PDFs.

This is probably getting into old man yells at cloud territory, but it's markdown... Open it in a text editor. That is the most of point of having markdown, nice looking plain text. typeset text is the side effect, if the point were typeset text I would hope that a better format than markdown was used.

If you try opening a .md file on Android it says "no viewer available", and offers you to pick from a list of Google Drive, Dropbox, ... It doesn't offer to open it in a text viewer. In fact, I'm not even sure Android has a native .txt viewer.

If you have a text editor installed, it'll ask you to open it in a text editor.

Android doesn't come with a text editor by default but there are loads of options out there. Same goes for any docx or even PDF if you don't have Google Drive installed.

Markdown is a plaintext format, that's what makes it great and got it adoption, it works without formatting! Rendering markdown is a nice to have, a luxury that gets very complex very quickly when done properly. If you want it, install a an application that does markdown rendering, I use Obsidian.

The fact that a file can't be opened as plaintext in a plaintext editor is not a problem with Markdown, it's an OS problem that effects any file you'd want to open as plaintext.

I was searching for a simple markdown viewer for Ubuntu.

Shockingly, I could only find about 3, and all sucked in their own special way.

I have the simplest of requirements: just format it and show it like a PDF. Either the app doesn't remember its position and always restarts in an awkward landscape format, or it insists in showing a "file tree" side bar, no simple file viewer.

Pretty sure you could paste your comment into a coding agent and get it to build exactly what you want

I love any appreciation of markdown, but I think this particular essay attacks the very basis of my sphinxian soul in two ways:

1. There’s no acknowledgement of the rich ecosystem of markdown dialects, which add all sorts of incredible features as simple as inline citations and as complex as full roles and directives. They all need highlighting.

2. There’s author claims to like markdown, but then it becomes clear that they don’t like markdown itself, they just like it being behind a rendered WYSIWYG editor. Which… :( headers should look like headers and tables should look like tables, yes, but not at the cost of removing any of the syntax characters! If you do, you’re sacrificing the whole point of the format: ease of modification.

Clearly their heart is in the right place, though. I absolutely loathe sites that don’t support markdown; there is *zero* reason not to do something _this_ important! ~~I dare say it would be something that the three mods and their uninvolved monarch should go to bed every night feeling ashamed of…~~

> headers and tables should look like tables, yes, but not at the cost of removing any of the syntax characters! If you do, you’re sacrificing the whole point of the format: ease of modification.

It's the opposite, you remove the major challenge in modification- change one char and break your whole table. It type an extra backtick and now paragraphs of text are misformatted. Add/remove a column? Ha-ha, where did you get so much time to waste? Join two cells? Oh, that's too complicated

Search and replacea phrase? Impossible to find, there are formatting markers between words.

Exactly, you just confirmed how complicated, complex and varied markdown rendering is, which is exactly why it should be left to markdown applications.

The OS should be able to natively open plaintext. The joy of markdown is it still largely works in plaintext.

> The joy of markdown is it still largely works in plaintext.

Except it doesn't because it isn't, the challenges above are from editing raw. There is no joy in reading/editing anything non-primitive in MD

Markdown was explicitly designed to be a lightweight markup language for formatting text in a plaintext editor.

You will not get any joy reading/editing non-primitive things in a markdown language not designed for reading/editing non-primitive things.

You will get joy from using the right tool for the right task.

> using the right tool for the right task.

which a plaint text editor is decidedly not since it fails at the most basic editing tasks - search and search&replace. That is the joy killer. Thus the tool described in the blog is closer to the right one for this task

Sorry, I can't think of a single plaintext editors, even going back to things like vi and ed, which don't support find and replace.

Markdown was designed for plaintext editors. Plaintext editors are - by the definition of markdown - a right tool for the job of markdown.

I don't have anything else to add here.

Sure, it’s not a spreadsheet application. But were talking about prose here, not spreadsheets. A lot of that is covered by editor commands and auto formatting, though definitely not the final example.

I think you might just be used to trying to edit markdown without any syntax highlighting…? The Bactic thing is particularly worrying. I don’t really understand how a changed inline fence could reflow whole paragraphs (i.e. effect multiple blocks) in the first place, but even if it were to, it should be obvious as soon as you type it due to changed highlighting.

And search and replace… I definitely don’t relate to that. Regex handles that pretty trivially, but I’ve also never run into the need to replace a phrase that is sometimes partially marked up — seems niche?

But you're the one who brought tables up? How does limiting to prose help? These are basic fails in simple tables used in prose all the time

> A lot of that is covered by

Almost none of this is, hence the examples.

> markdown without any syntax highlighting

The opposite, syntax highlighting is the only saving grace.

> it should be obvious as soon as you type it due to changed highlighting

Do you know that people copy and paste sometimes? Your "obvious" becomes a needle search operation to find which symbol broke it. Or it may be hidden in the middle of a page.

> Regex handles that pretty trivially

How? Write your trivial regex to exclude arbitrary html markup between words. Start with a simple example of a bold word with multiple maker types, extend into adding color and maybe a tag? Then estimate how many 0.0x% of users in the bright future of universal md support would know what regex is.

> I’ve also never run into the need to replace a phrase that is sometimes partially marked up — seems niche?

That's unfortunately a common issue - people with very primitive document editing experiences where broken search is a non issue suggesting their workflows for the masses

So you send a PDF file to somebody with a fresh install of Windows and they can open it? Really?

Yes, Edge is the default PDF reader on Windows.

Notepad on Windows opens markdown files and you can toggle formatted or syntax view. What am I missing?

I miss when Notepad just opened plaintext files as they were.

Does it not?

not on 10

Not sure that's relevant. 11 was released 5 years before the blog post and support for 10 ended 1 year before the blog post.

Do you have an app for that?

$ claude

⟩ Write me a Markdown file viewer for ${OS} that shows Markdown files as formatted documents by default. A button should toggle between the formatted view and the raw Markdown file as plain text. Work the task to completion and make no mistakes.

Wait, do people actually tell LLMs to not make mistakes? Does it actually help or is it just one of those things like using Please etc?

It was a thing in the early days of LLM coding that actually got better (not great) results. It's far less necessary today but you still see it used as a joke much like the canonical AI response, "You're absolutely right!" (which I also haven't seen in yonks)

Off topic, but Sol and Astra are now constantly starting their answers with “Yes”.

You can set VSCode to open it by default. There is even Cmd+Shift+V for previewing the rendered Markdown.

I want any browser to render MD content natively. Imagine just dropping .md files to your server and having a working website.

Of course, there are services that do that for you, ranging from Hugo to Obsidian Publish. But they all add a level of complexity that you have to manage.

Also, this makes user-level styling much simpler. This is what any “Reading mode” does, but without reverse-engineering the content from a soup of tags and classes.

I use https://addons.mozilla.org/en-GB/firefox/addon/markdown-read... and so, for me, they do render natively.

I'm thinking about registering a mirror of my website on .md TLD (Moldova) and serve MD version of my site. This is for users who, like you, have an extension installed, and would prefer to configure the styling themselves. Or for AI agents, I guess.

You'd only get plain unstyled rendering with browser support. And at that level you don't need any complexity from Hugo or Obsidian - you only need a very simple script to convert md to plain html. No config or anything to maintain.

> You'd only get plain unstyled rendering with browser support

What I imagined is browsers rendering the content with headings, quotes, etc. Browsers could have some default styles to render MD files. Those styles could be configurable the same way “Reading mode” is usually configurable.

The plain unstyled rendering of strings of text is, of course, available even now. That's why I'm saying this needs a browser-level support.

> you only need a very simple script to convert md to plain html

I get, that it feels simple compared to other software. Even more, MD was designed specifically to be simple!

But if you think about it, this is still too much complexity to just share some text.

With native browser support, you could run zero commands to build a website.

I think this is mostly important for regular users, not developers. Imagine if creating a Word document would require the same level of complexity as building a web page: I doubt that the format would be so popular as it is nowadays.

> Imagine just dropping .md files to your server and having a working website

Why imagine. That's what I do, except it's a cron that runs the shell script that converts all the markdown to html.

> cron that runs the shell script

So then you don't just drop a .md file.

> So then you don't just drop a .md file.

I literally do - I drop a file in a folder; the fact that everything else is automated is irrelevant, because all I do is drop a file in a folder.

> the fact that everything else is automated is irrelevant

It is relevant because you're the one that wrote the script to automate it.

Sure, it works for you. But it doesn't work for everyone else, which I think was the other person's ideal when they said:

Imagine just dropping .md files to your server and having a working website

They didn't literally mean your server.

Not only that, but also generally maintaining the script is a new responsibility. Adding browser-level support of .md files shifts this responsibility to the browsers, which, if you ask me, is where it belongs.

I've been asking for this for many years. Native browser support in markdown will also give us a way to set our browser agents to prefer text/markdown over text/html, and thus opt-in to a cleaner web. Yes, I know you can embed HTML in markdown, but I would can hope it would work much like AMP except more open - with browsers deciding on what commonmark extensions they enable by default.

I just want Google Docs to properly support Markdown. Everything else after that.

All requests to this site are responding 404 at present.

I've had the same issue but turning VPN on fixed it.

Every time I install Xcode it decides that it's the default markdown reader. If anybody at Apple could fix this, that'd just be swell.

Agreed. Firing up a 12gb app to read markdown seems like overkill

I built a small but polished native mac markdown reader that you can install, and if you set it as the default handler of markdown files, xcode wont highjack it, I just tested that with my update to macos/xcode 27. It's currently waiting review to be published on the app store, but you can download directly from my webpage. it's open source.

https://nano.thirdeyeds.com/

I have something better:

Mobile computing should be more like desktop computing.

I think we need a different default format than Markdown. Markdown has never had a single standard. Tables were invented by GitHub and were never included in the CommonMark standard. Line breaks are weird for non-Latin languages like Chinese, and for historical reasons, you need two asterisks (**) to bold a word. It is also troublesome to parse.

We need a better markup language.

AsciiDoc solves a lot of problems Markdown created, but it's got its own problems. At least it doesn't just inject HTML tags all over the place to work around limitations.

I'd settle for just saving CommonMark files with a dedicated file extension, most people think of CommonMark when they say Markdown anyway.

Relevant xkcd: https://xkcd.com/927/

The nice thing about standards is there so many to choose from. Sure, we can add another one.

John MacFarlane, the creator of Pandoc, invented the Djot format to solve many of these issues. It's derived from CommonMark and smooths out the parts of CommonMark's syntax that make it complex and slow to parse. It's not seen huge success so far, but I like it.

https://www.djot.net/

Just recently created an md live viewer/pdf exporter after feeling some of these same frustrations[0]. Always wanted something that allowed me to use vim while viewing the markdown exactly as it would render to pdf, kind of like overleaf.

[0] https://github.com/john-marinelli/docm

> Markdown has been around for more than 20 years

Yet as you note later there is no such thing as a singular markdown. So why would time do magic here? There is nothing remarkable about bad underspecified system suffering from incompatible variety for decades, computers are littered with examples of those

> One of the original ideas behind Markdown was that a document should remain readable even before a computer interprets its formatting

Which was never true since it includes HTML which you criticize in the very next sentence

> We have spent decades dealing with document formats that behave differently depending on which application created them, which version of the software is installed and which operating system is trying to open them. Markdown should be an opportunity to move in the opposite direction.

Weird, MD has all the same issues, why would it present any opportunities?

Just treating .md files as text files would get us 90% there. The whole point of markdown is that it’s readable as text.

is there a laymen training guide on markdown?

How do I teach someone who never opened anything besides excel, word, and powerpoint about markdown? to them the document file is just a document and it opens in word that's mostly what they know for this audience.

as always, i love the "mount it trivially with curlftpfs" comments here

Anyone who cares about Markdown has an IDE available anyway. Or they probably have strong opinions about what a Markdown viewer should or shouldn't do.

Just opening in notepad by default works fine. The point of markdown is that it doesn't need rendering to be readable. If you need more, you already have a preferred Markdown IDE setup anyway.

Markdown is pretty terrible as a rendered format anyway. The standard for Markdown itself is extremely loose so we invented several types of Markdown, indistinguishable from each other with slightly different features and syntax, to cover the loose standard. CommonMark isn't Markdown yet I see nobody saving files as .cm to actually indicate what kind of Markdown they need.

This is a major annoyance in messaging apps, slop tooling, and of course git GUIs. Building a standard viewer will bring all of those problems to the operating system, and for what? To annoy the people who already have a Markdown viewer of choice?

> Anyone who cares about Markdown has an IDE available anyway.

I think the point being made is that users who do not care about Markdown will receive Markdown files, and it should be trivial for them to open and view them.

Yes, the article also states “If I want to see the original Markdown syntax, I should be able to switch to that view just as easily”, which isn’t necessary for that use case, but I still think that’s a point the author makes.

> We have made something simple unnecessarily complicated.

Oh, but Markdown isn’t simple. Easy it is, certainly, but simple it isn’t because of one feature: being able to embed HTML. So the semantics of Markdown subsumes the semantics of HTML, which has a _huge_ spec.

What one’d like in many cases would be a Markdown-without-HTML-embedding. But that’s no longer Markdown.

Just installed a markdown renderer extension to firefox, then set firefox as the default program for markdown files.

ez, wish the browsers had nice rendering out of the box and registered themselves as a handler though

A markdown file it's easily readable text. No need for any special treatment out of the box to handle, so no need for anything more than a text editor. PDF is a binary format, similar to images, videos, etc so of course they need special viewers. And I can still remember the days when I had to go hunting for a decent PDF viewer (and MP3 player). There's no comparison here when you can open a markdown file in literally any text viewer/editor out there and read it with little to no issue.

I think https://markdownlibrary.app ticks all the boxes. It leaves files where they are. It allows editing raw. And it keeps track of all the markdown files across multiple repos WITHOUT moving them to a vault. And yes - it can open md files by default.

I am obviously biased but this is what I needed, too.

I read a lot of .md my agents wrote, and I want the best experience working with agents on the markdown files.

So I built https://markside.app

A free, lightweight Chrome extension that renders local .md files.

No need to open another app. No need to have a vault to just view the files.