What is an MD file?

MD is a plain-text format you can open in any editor. It is used for editing and moving data between programs.

The extension is .md, and the full name is Markdown. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 2004. The specification is CommonMark.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

Visual Studio Code, Obsidian and Typora read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

MD is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

Markdown exists because writing HTML by hand is tedious and writing in a word processor produces a file nobody can diff. It is a set of conventions that were already in use in plain-text email long before they had a name: a line starting with a hash is a heading, asterisks around a word make it bold, a hyphen at the start of a line makes a bullet. The point is that the source stays readable even to somebody who has never heard of the format.

That property is why it took over documentation. A README, a changelog, a technical note or a blog post written in Markdown is a text file — it goes in version control, two people can edit it and merge the result, and a reviewer can read the diff without rendering anything. No binary word-processor format allows any of that.

There is no single Markdown. The original description from 2004 was informal and left a great deal undecided, so implementations filled the gaps differently. CommonMark is the serious attempt at a precise specification and is what most modern editors follow. GitHub Flavored Markdown is CommonMark plus a handful of additions, and it is the version most people have actually used.

The addition that causes the most confusion is tables. Pipe-delimited tables are not part of CommonMark — they are a GitHub extension, also supported by many editors and by plenty of static-site generators, and absent from strict implementations. A table that renders perfectly in a repository and comes out as a row of pipes elsewhere is not a broken file; it is a file using an extension the other tool does not implement. Task lists, strikethrough and automatic links are extensions in the same category.

Many Markdown files open with a block fenced by three hyphens containing something like a title, a date and a list of tags. That is front matter — usually YAML, occasionally TOML or JSON — and it is not Markdown at all. Static-site generators, note-taking applications and documentation builders read it as metadata about the document and strip it before rendering.

A tool that does not know about front matter shows it as literal text at the top of the page. If a converted document starts with three hyphens and a list of key-value pairs, that is what happened, and deleting the block before converting is the fix.

There is no page size, no margin, no font, no line spacing, no page break and no footer. This is a feature rather than an omission: the file describes structure — this is a heading, this is a quotation, this is code — and leaves appearance to whatever renders it. The same document becomes a web page, a PDF and a slide deck without being rewritten.

It also has no comments, no tracked changes and no way to say "this paragraph is the third revision". Version control does that job instead, and does it better, which is the trade the format is making. If a document needs review workflow rather than history, a word processor is the honest tool.

The usual destination is PDF, for anything being sent to somebody who does not care what it was written in — a specification handed to a client, a set of notes, a manual. The conversion turns the structural marks into real formatting: headings become headings, code blocks keep their monospaced font, and lists keep their nesting.

HTML is the other common target, and it is closer to a translation than a conversion since Markdown was designed as a shorthand for it. Converting to DOCX is worth knowing about for a specific situation: a document you want to write in a text editor and hand to somebody who will only accept a Word file with tracked changes.

A Markdown file that shows six diagrams contains no diagrams. It contains six paths, and the images sit beside it on disk or on a server. Move the file without the folder around it and every image is gone.

This matters at conversion time. A converter can only embed a picture it can find, so relative paths have to resolve from where the file actually is. It matters again when a document is emailed: sending someone a .md file with no assets is sending them the skeleton. If the images are the point, convert to PDF, where everything ends up inside one file.

Any text editor will do — Notepad, TextEdit, nano — because the file is text. That is the whole appeal, and it is why a Markdown document written in 2004 opens today with nothing installed.

Dedicated editors add a live preview, which is genuinely useful while writing and completely irrelevant to the file. Visual Studio Code, Obsidian and Typora all render as you type; none of them stores anything the others cannot read. Choosing one is a preference, not a commitment, which is more than can be said for most document formats.