by Joshua Morris, October 13, 2026
\nIt seems strange to me that in 2026 we still cannot open a Markdown document on just about any computer or phone and expect it to display properly without installing additional software. Markdown has been around for more than 20 years and has become an essential format for documentation, writing, publishing and sharing information. It is simple, portable, human-readable and supported by an enormous collection of applications and websites. Yet something as ordinary as receiving a .md file can still leave people staring at raw formatting syntax or looking for an application capable of displaying it as a document. We have operating systems that can open photographs, play videos, read PDFs and recognize countless complicated file formats without requiring us to think about how any of that works. I think Markdown deserves the same treatment.
I have been using Markdown for years, and it has become one of my favorite ways to write and organize information. Much of the content on my personal website begins as Markdown because it allows me to focus on writing rather than formatting. I can keep those files in Git, edit them with almost any text editor, convert them into webpages and preserve the original documents without depending on a proprietary application. There is something wonderfully reassuring about knowing that the words I write today should remain accessible decades from now, even if every application I currently use disappears. A Markdown document does not require an account, a subscription, a particular company or a complicated file format to remain useful. That simplicity is precisely why I think it should be treated as a first-class document throughout the computing world.
\nOne of the original ideas behind Markdown was that a document should remain readable even before a computer interprets its formatting. John Gruber introduced the format in 2004 with help from Aaron Swartz, using ordinary text conventions to represent headings, links, emphasis and other common document structures. The result was a way to write structured material without surrounding every sentence with HTML tags or working inside a specialized document editor. Anyone who has opened a README file in a software repository has probably encountered Markdown, even if they did not know what the format was called. Its usefulness eventually spread far beyond programming into books, technical documentation, academic notes, publishing systems and personal knowledge collections. The format succeeded largely because it required so little from the software used to create it.
\nThat is what makes the current situation so frustrating. Markdown is already plain text, so nearly every operating system can technically open it with some kind of text editor. The missing piece is treating the file as a document instead of merely displaying the characters used to describe its formatting. A heading should look like a heading, a table should look like a table, and a link should behave like a link. If I want to see the original Markdown syntax, I should be able to switch to that view just as easily. None of this should require finding an obscure utility, installing a preview extension or moving the document into an application that converts it into another format.
\nI can send someone a PDF with a reasonable expectation that their computer or phone will know what to do with it. They can usually open the file, read the contents, search for text and navigate the document without worrying about which company manufactured their device. Markdown should be at least that easy to read, especially considering how much simpler the underlying format is. Unlike PDF, Markdown is also designed to be edited directly, which makes consistent support even more valuable. A person should be able to read a document on their phone, make a correction on their laptop and continue working on a tablet without changing the underlying file. That is the sort of experience we should expect from a modern operating system.
\nI initially started thinking about this because of the inconsistent experience across Apple's operating systems. Apple has added Markdown import and export to Notes, which I was happy to see, but importing a document converts it into the rich-text format used by Notes. That is useful for moving information between applications, but it is not the same as opening the original Markdown file, editing it and saving it in place. Finder, Quick Look and Files already understand how to present many kinds of documents, yet Markdown still does not have a complete native viewing and editing experience across macOS, iOS, iPadOS and visionOS. I would like to see that change because a Markdown document should not require a different workflow depending on which Apple device happens to be in my hands.
\nThis is not exclusively an Apple problem, however, and I do not think the solution should be limited to Apple's ecosystem. Windows, Linux, Android and every other modern computing environment should recognize Markdown as an ordinary document format. Microsoft has made encouraging progress by introducing Markdown formatting directly into Windows 11 Notepad, including the ability to switch between formatted text and Markdown source. Linux has a wonderful collection of text editors and Markdown tools, although the experience varies between distributions, desktop environments and installed applications. Android also has plenty of capable third-party Markdown editors, but that does not guarantee a consistent formatted reading and editing experience through the default file-handling system. We have pieces of the solution scattered throughout the industry without a common expectation that the experience should work everywhere.
\nI do not expect every operating system to render Markdown with identical fonts, spacing or visual styling. In fact, I would prefer that the presentation respect the user's own system settings and accessibility preferences. What should remain consistent is the structure of the document and the ability to work with the same underlying file. A Markdown document created on Linux should open naturally on Windows, remain editable on Android and display properly on an iPhone. The person using the file should not have to understand which application originally created it or which Markdown rendering engine the operating system uses. That is the kind of interoperability that makes a format genuinely useful across different platforms.
\nThe interesting part is that much of the difficult work involved in agreeing on how Markdown should behave has already been done. The original Markdown syntax left some behavior open to interpretation, which eventually produced differences between applications and rendering engines. The CommonMark project addresses those ambiguities by providing a well-defined specification and extensive examples for implementers. GitHub Flavored Markdown builds on that foundation with widely used features such as tables, task lists, strikethrough and automatic links. Those conventions already support an enormous amount of documentation and written material circulating around the internet. Operating system developers do not need to invent another document format to make this work.
\nThere will always be extensions that particular applications support and others do not. Some writers use footnotes, mathematical notation, diagrams, embedded HTML or specialized publishing syntax that goes beyond CommonMark and GitHub Flavored Markdown. I do not expect every built-in document viewer to reproduce every possible extension exactly. What I do expect is a reliable baseline that renders ordinary Markdown correctly while preserving anything the application does not understand. Opening and saving a file should never silently discard unfamiliar syntax just because the built-in editor does not know how to display it. The entire point of using a portable text format is that applications should not need to control every possible feature to preserve the document.
\nThere are also sensible security considerations whenever an operating system renders documents from unfamiliar sources. A Markdown preview should not execute arbitrary scripts, load untrusted content without appropriate safeguards or expose information simply because the file references an external resource. Those are familiar problems that operating systems already handle when presenting PDFs, HTML and other document formats. A renderer can provide useful formatting while treating the underlying file as untrusted content. It can also work entirely offline for ordinary documents, without requiring a cloud service to interpret a few headings and paragraphs. Markdown's simplicity should make it easier to build a safe native experience rather than another excuse to move document processing onto somebody else's servers.
\nOne of the unexpected developments of the past few years is how prominently Markdown has appeared in the growing ecosystem of artificial intelligence. Language models frequently use Markdown conventions to organize their responses because it provides a convenient way to communicate headings, lists, tables, code and other structured information through ordinary text. Developers use Markdown for agent instructions, project documentation, technical specifications and the many files that help AI tools understand the software they are working on. People who have never written code are encountering Markdown through exported conversations, generated reports and documents produced by AI services. The format has effectively become one of the common languages through which people and software exchange structured written information. I suspect that visibility will continue increasing as AI becomes part of more everyday workflows.
\nThat makes native support feel even more overdue. We are building increasingly sophisticated tools that can interpret enormous documents, summarize complex research, write software and generate entire reports, yet an ordinary computer may still need another application to display the resulting Markdown file as a nicely formatted document. I find that contrast a little ridiculous. We should not need artificial intelligence to understand how to display a heading written with a hash symbol. The operating system should already know how to do that. Making Markdown a normal part of the document experience would help ordinary users benefit from the format without needing to understand the technical conventions underneath it.
\nIt would also encourage more applications and services to exchange actual documents rather than forcing people into proprietary formats. If I ask an AI system to generate a report, I would love to receive a Markdown document that I can open, edit, archive and publish wherever I choose. I do not want the usefulness of that document to depend on returning to the service that created it. The same should be true of notes exported from a writing application, documentation downloaded from a website or information shared between coworkers. Markdown offers a straightforward way to exchange structured content without requiring every participant to use the same software. The operating systems simply need to make that experience approachable for everyone.
\nThis connects to something I have been thinking about quite a bit while working on my personal website and exploring the independent web. I want people to have greater ownership of the things they create, including their writing, photographs, documents and personal archives. Too much of our digital lives has become dependent on applications and services that store information in formats we cannot easily access outside their ecosystems. The company providing the service may change its business model, increase prices, discontinue a feature or shut down entirely. Sometimes it offers an export function, but the exported material may be difficult to use without finding another application capable of interpreting it. We should not have to wonder whether we will still be able to read our own writing after the company holding it decides to move on.
\nMarkdown is appealing precisely because it avoids much of that dependency. A document can sit on a hard drive, USB stick, home server, cloud drive or Git repository without requiring any special service to keep it alive. It can be copied, searched, versioned, backed up and transformed into other formats using tools that have existed for years. If I stop using one writing application tomorrow, I can open the same file in another application without having to perform an elaborate migration. That freedom becomes particularly important for material I intend to preserve over a long period. I would much rather build my personal archives around files that remain understandable than around a database owned by a company whose future I cannot control.
\nNative Markdown support would strengthen that freedom by removing one of the remaining inconveniences of choosing portable files. People could use whatever application they enjoy without worrying about whether a recipient has installed the same software. An operating system's built-in viewer would provide the dependable fallback, while specialized editors could continue offering additional features for people who need them. That would be good for developers, but it would also be good for writers, students, teachers and anyone else who wants to keep their documents independent of a particular application. A file format becomes much more approachable when opening it does not require any special knowledge. I think that is an important part of making digital ownership practical rather than merely possible.
\nThe last thing I want is for Apple, Microsoft, Google or anyone else to take Markdown and create a slightly incompatible version that works best inside their own products. 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. Common conventions, open specifications and plain-text storage already provide a foundation that the entire industry can share. Each operating system can build a native experience around those conventions without claiming ownership of the document format. The original file should remain the source of truth, regardless of which application is currently displaying it.
\nI also do not believe native support would eliminate the need for dedicated Markdown applications. There are excellent editors that provide publishing tools, syntax extensions, document management, collaboration, themes and workflows that would be unreasonable to expect from an operating system's basic document viewer. People should absolutely continue building and using those applications. Native support would simply establish the minimum experience that everyone can expect without additional software. An image viewer does not replace Photoshop, and a built-in PDF reader does not eliminate the need for professional document tools. A native Markdown viewer would serve the same purpose while allowing more specialized applications to build upon a common foundation.
\nThat minimum experience should include formatted previews in file managers, proper reading views, a basic editor, access to the underlying source and the ability to save changes directly to the original .md file. It should support document structure, including headings, paragraphs, lists, links, tables, images and code blocks, with accessibility features that make the content useful to people with different needs. It should work with local files and whatever file providers the operating system supports, without requiring conversion into another application's internal storage. None of those features is particularly exotic, and many are already available through individual applications today. The missing piece is making them dependable parts of the operating system rather than optional additions that users have to discover for themselves.
I find it remarkable that we have managed to make Markdown so useful without the major operating systems ever agreeing to treat it consistently as a native document format. The software development community has embraced it, publishing systems rely on it, independent websites use it, and AI tools are introducing it to an entirely new audience. Its longevity suggests that the format is doing something right, particularly in an industry where technologies regularly appear and disappear in a matter of years. We do not need to replace our existing office documents, PDFs or specialized publishing formats with Markdown. There is room for all of those tools because they solve different problems. I simply think Markdown has earned a place alongside them as a document format that anyone should be able to open and use.
\nI would love to see Apple, Microsoft, Google, the Linux desktop communities and other operating system developers recognize the opportunity here. Each has already built much of the infrastructure required to present documents, edit text, synchronize files and make information accessible. Supporting Markdown properly would connect those capabilities to a format that is already widely used and does not require anyone to surrender control of their documents. It would make sharing information between different devices and operating systems a little easier, which is something the computing industry still manages to make unnecessarily complicated. It might also encourage more people to choose open formats when creating things they want to keep for years. That would be a meaningful improvement even if most users never gave the underlying technology a second thought.
\nI do not think this needs to become a grand new initiative or another complicated application that competes for our attention. I want to double-click a Markdown file on my computer and have it open as a document. I want to receive one on my phone and read it without installing anything. I want to make a correction, save the file and know that the original Markdown will still work wherever I open it next. Most importantly, I want people to benefit from an open document format without needing to understand why that openness matters in the first place. We have had more than 20 years to make Markdown an ordinary part of computing, and I think it is time we finally did.
\nCommonMark documents a consistent Markdown specification, while the GitHub Flavored Markdown specification defines widely used extensions. Microsoft's Windows Notepad Markdown announcement and Apple's Markdown import and export documentation illustrate two different approaches to bringing the format into built-in applications.
","headings":[{"level":1,"text":"A Markdown File Should Just Open","id":"a-markdown-file-should-just-open"},{"level":2,"text":"We have made something simple unnecessarily complicated","id":"we-have-made-something-simple-unnecessarily-complicated"},{"level":2,"text":"Every operating system should understand Markdown","id":"every-operating-system-should-understand-markdown"},{"level":2,"text":"We already have the standards","id":"we-already-have-the-standards"},{"level":2,"text":"Artificial intelligence is making Markdown even more important","id":"artificial-intelligence-is-making-markdown-even-more-important"},{"level":2,"text":"The file should belong to the person who created it","id":"the-file-should-belong-to-the-person-who-created-it"},{"level":2,"text":"I don't want another proprietary document ecosystem","id":"i-don-t-want-another-proprietary-document-ecosystem"},{"level":2,"text":"Markdown deserves to become an ordinary document","id":"markdown-deserves-to-become-an-ordinary-document"},{"level":2,"text":"Further reading","id":"further-reading"}]}}