Markdown 是一种轻量级标记语言，用简单的语法就能为纯文本添加标题、列表、链接、代码块等格式。它由 John Gruber 于 2004 年公开，设计理念是 "易于书写、易于阅读、易于转换为 HTML"。在打磨语法的阶段，Aaron Swartz 担任了商讨对象，Swartz 于 2002 年做出的 atx 记法，成为了用连续的 # 表示标题这一写法的底本。名称是与 HTML (HyperText Markup Language) 中的 "markup" 成对的造词。

Markdown 的基本语法很简洁：用 # 写标题，用 -、*、+ 中的任意一个写列表，用 [文本](URL) 写链接，用 `代码` 写行内代码，用 ``` 写代码块。这种简洁性是它最大的强项，编写文档的速度远远快于直接书写 HTML 标签。同一种格式备有多种写法也是它的特征。标题除了并排 1-6 个 # 的 atx 形式之外，也可以用在下一行以 = 或 - 像下划线那样填满的 setext 形式来表示。列表的 3 种符号无论选哪一个，结果都相同。也就是说，获得同一外观的手段有多种，因此源文件的字符数会随书写者的习惯而变化。

它在 GitHub 的 README、技术博客、文档站点 (MkDocs、Docusaurus、VitePress)、聊天工具 (Slack、Discord)、笔记应用 (Notion、Obsidian) 等面向开发者的工具中被广泛采用。作为标准化规范，CommonMark 与 GitHub Flavored Markdown (GFM) 是主流。GFM 被定义为 CommonMark 的严格超集，规范主体仍然遵循 CommonMark，只是在表格、删除线、自动链接、任务列表这 4 项之外，再加上将危险的原始 HTML 标签无效化的 tagfilter，共 5 项定义为扩展。用 CommonMark 写的文档可以原样在 GFM 中通过，但反过来并不成立。把握住这种不对称，就更容易预测在方言之间迁移时会坏掉的地方。

Markdown 的优点在于，即使作为纯文本也足够易读，没有专门的编辑器也能编辑。它与 Git 的版本管理相性也好，差异的确认很容易。另一方面，表格、脚注、数学公式等复杂格式的支持情况因方言而异，有时会产生兼容性问题。此外，由于可以在 Markdown 中直接书写 HTML，所以仅靠 Markdown 无法表达的排版也能实现。不过原典的规范附有条件：<div> 或 <table> 这样的块级元素需要用空行把前后隔开，而且在它们的内侧不会处理 Markdown 的记法。用 HTML 的表格时，即使在单元格里写 **粗体** 也不会变成粗体，而是连符号一起显示出来，原因就在这里。相对地，<span> 这样的行内元素可以在行的中途使用，内侧的 Markdown 也会被处理。

一个常见的误解是认为 Markdown 是单一的规范，而实际上存在众多方言 (风格)。有原始的 Markdown、CommonMark、GFM、MultiMarkdown、Pandoc Markdown 等，各自的扩展语法不同。在项目中使用时，事先明确遵循哪个规范非常重要。

从字符计数的角度看，Markdown 的记法字符 (#、*、[]、() 等) 在显示时不会被渲染出来，因此源文件的字符数与显示上的字符数会产生差异。例如 **粗体** 在源文件中是 6 个字符，显示上却是 "粗体" 这 2 个字符。差异变得最大的是链接和图片。[链接文本](https://example.com/page) 在源文件中有 32 个字符，而被显示出来的只有 "链接文本" 这 4 个字符，URL 的长度会原样变成差额。图片的 ![图片替代文本](https://example.com/img.png) 即使耗费 38 个字符，作为正文显示出来的字符也是 0 个。想把记法字符本身当作字符显示出来时，就在它的前面放上 \ 来转义。\* 在源文件中是 2 个字符，显示则是 "*" 这 1 个字符。会成为转义对象的符号范围很广，包括 \ 与反引号、*、_、各种括号、#、+、-、.、!。反过来，也有一些字符不出现在显示上却不能删掉。有一种记法是在行尾放上 2 个半角空格就成为段落内的换行，一旦经过会自动去掉行尾空白的编辑器或 trim 处理，这 2 个字符就会连同换行本身一起丢失。在决定是否把空白计入数量之前，先把握住 "消失的空白有时会改变显示" 这一点更为稳妥。以哪一边的字符数为基准，取决于投稿目的地在数什么。有些场合按渲染后的外观来判断更自然，但如果输入框的上限或 API 一侧的校验是针对源文件的字符串起作用，那么含记法字符的源文件一侧的字符数就会起效。想确认草稿是否收得进上限时，请先确认被数的究竟是源文件还是转换后的正文。