I'm fairly new to all this, but my understanding is that Markdown is great for a few reasons:
It's just plain text, so no vendor lock-in and you can ripgrep/fzf/grep through it Lives happily in git repos with proper diffs LLMs speak it natively - they output Markdown, they understand Markdown input Way easier for agents to parse than PDFs (which are binary, layout-focused, tables turn to mush) Can do tables (at least in GFM), headers, code blocks, links - all structure preserved
What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering. Am I missing anything? What are the other limitations I should know about?
> What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering. Am I missing anything? What are the other limitations I should know about?
Multi-level lists, annoyingly, get rendered as code at the deeper levels because of the 4+ spaces from the beginning of the line.
This is a serious and major drawback of markdown, making it good for developers only. The average person does not want to render code.
Remove that one drawback, and it'll get even better adoption.
(CommonMark) Markdown is a rough superset of HTML, like how YAML is a superset of JSON. So whatever can be expressed in HTML can also be expressed in Markdown. With the way the CommonMark spec is written, Markdown is effectively just an HTML preprocessor.
A major limitation of Markdown is the lack of standardization. For example, even within GFM there's multiple subtle variants: a single new line becomes a space when rendering Markdown files, but a line break in issue comments.
> What are the other limitations I should know about?
It's completely inadequate for anything more than a memo or simple single-page note. Which is fine for many purposes a typical software developer encounters but quickly gets left behind for anything more.
It's exclusively a markup language, completely lacking in semantic meaning. If you're trying to write an actual document, the title is the title not some bold text in a bigger font, for example.
Like a hammer, it's a great tool for certain jobs. So many people assume all their writing tasks are nails.
> What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering. Am I missing anything? What are the other limitations I should know about?
Off the top of my head: Math typesetting, semantic markup, small caps, document sectioning. (All of these things are very important for me.)
> What it can't do (as far as I understand): complex layouts, precise typography,
Some "extended" flavors will allow you to embed HTML and CSS which solves the layout problem. It's not really markdown at that point, though.
> embedded binary content,
If you're using one of the extended variants, you can b64 encode images... but again, that's not really the spirit/intent of markdown.
The lack of viewers for it.
> What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering.
Please see:
* https://impacts.to/downloads/lowres/impacts.pdf
* https://keenwrite.com/docs/user-manual.pdf
* https://keenwrite.com/blog/2025/09/08/feature-matrix/pdf/jek...
* https://keenwrite.com/blog/2025/09/08/feature-matrix/pdf/sof...
Those are Markdown documents typeset using ConTeXt. Except for Jekyll & Hide, I wrote them all.