Markdown は、プレーンテキストに簡易な記法で見出し、リスト、リンク、コードブロックなどの書式を付与できる軽量マークアップ言語です。2004 年に John Gruber が公開したもので、「書きやすく、読みやすく、HTML に変換しやすい」という設計思想のもとに作られました。構文を練る段階では Aaron Swartz が相談相手を務めており、Swartz が 2002 年に作った atx の記法が、# を並べて見出しを表す書き方の下敷きになっています。名前は HTML (HyperText Markup Language) の「マークアップ」と対になる形の語です。

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 に従ったまま、テーブル、取り消し線、オートリンク、タスクリストの追加に、危険な生 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 側の検証がソースの文字列に対して働くなら、記法文字を含めたソース側の文字数が効いてきます。下書きが上限に収まるかを確かめたいときは、数えられているのがソースなのか変換後の本文なのかを先に確認してください。