它們不是競爭者 - Markdown 的終點就是 HTML
- Markdown 不是 HTML 的替代品。每一份 Markdown 檔案在被人看到之前，都會先變成 HTML。
- Markdown 涵蓋的是文章需要的部分：標題、段落、強調、清單、連結、圖片、程式碼。
- 一旦需要版面、表單、嵌入元件或精準控制，就換 HTML 上場。
- 實務上的答案是：主體用 Markdown 寫，少數真的需要的地方才插入 HTML。
有一個事實幾乎就能終結這場爭論：Markdown 的全部工作，就是變成 HTML。John Gruber 與 Aaron Swartz 在 2004 年並不是想取代 HTML，而是替「寫文章真正會用到的那一小塊 HTML」發明一套更友善的記法。
Markdown 涵蓋的是哪一塊
那一塊刻意做得很小：標題、段落、強調、清單、連結、圖片、程式碼，就這些。你寫的每一份 Markdown 檔案，最後都會經過轉換器，輸出成 <h1>、<p>、<strong> 這些標籤。這些元素怎麼用，完整 Markdown 指南逐一講解過。
真正該問的是：你要在哪一層寫？
問「該用 Markdown 還是 HTML？」有點像問「該要食譜還是那道菜？」一個是好讀的原始稿，另一個是完成品。真正有用的問題是：你想把寫作時間花在哪一層？
寫文章的話，答案是 Markdown 這一層。打字更快，一個月後回頭看也輕鬆得多。超出文章範圍的東西 - 複雜版面、互動元件、像素級的控制 - 就下沉到 HTML 那一層，那裡才有完整火力。如果兩種語言你都還很陌生，我們的 Markdown 白話入門十分鐘就能講完基礎。
同一份內容，兩種寫法並排看
要分出高下，最快的方法就是把一模一樣的內容用兩種記法各寫一次。以下是一份迷你文件：一個標題、一段含粗體的文字、一個清單、一個連結。先看 Markdown 版：
# 週末旅行清單
這次別再忘記帶**相機電池**了。
- 護照
- 充電器
- 雨衣
到 [Riverside Inn](https://example.com/riverside-inn) 訂飯店。
再看手寫 HTML 的同一份文件：
<h1>週末旅行清單</h1>
<p>這次別再忘記帶<strong>相機電池</strong>了。</p>
<ul>
<li>護照</li>
<li>充電器</li>
<li>雨衣</li>
</ul>
<p>到 <a href="https://example.com/riverside-inn">Riverside Inn</a> 訂飯店。</p>
兩份檔案在瀏覽器裡產生的頁面一模一樣。所有差異都發生在那之前，也就是人還在打字、還在讀的時候。
三個一眼可見的差異
- 可讀性。Markdown 版幾乎就是一張普通便條，直接貼進 email 寄出也毫無違和；HTML 版卻把同樣六行內容埋進滿滿的角括號裡。
- 打字成本。Markdown 版的字元數大約只有一半，而且不必反覆按住 Shift 去打
<和>。 - 出錯機率。HTML 壞起來又安靜又難看：漏掉一個
</ul>，後面整頁的巢狀結構都可能跟著壞。Markdown 幾乎沒有「忘記關閉」這回事。
Markdown 最糟的錯字通常只是原樣顯示出來，你當場看得到、當場就能改，這正是即時預覽編輯器存在的意義。也看看那個清單：三個連字號，對上三組標籤。這套速記法在項目開始巢狀後還能撐多遠，Markdown 清單語法寫得很清楚。
正面對決：八個關鍵指標
以下用大家挑選寫作格式時真正在意的指標，把兩者放上同一張表：
| 指標 | Markdown | HTML |
|---|---|---|
| 學習曲線 | 幾分鐘 - 十多個符號就涵蓋 95% 的寫作需求 | 數天到數週 - 標籤、屬性、巢狀規則，還要學 CSS 才好看 |
| 原始碼可讀性 | 極佳；不渲染也像一份正常文件 | 寫文章時很差；內容和標記混雜在一起 |
| 寫作速度 | 快 - 符號短，不打斷思路 | 慢 - 每個元素都要開標籤、關標籤 |
| 精準度／控制力 | 僅限常見的文件元素 | 完全掌控 - 任何結構、屬性、class 或嵌入元件 |
| 語意化輸出 | 預設就好；轉換器輸出乾淨的語意標籤 | 取決於作者功力；一不小心就是一堆 div 疊 div |
| 可攜性 | 絕佳 - 純文字到哪都能開，可轉 HTML、PDF、DOCX | 瀏覽器通吃，但要再轉成其他格式很費工 |
| 工具生態 | 所有筆記軟體、靜態網站產生器、論壇；還有 MD Editor 這類編輯器 | 完整的 IDE 生態、linter、瀏覽器開發者工具 |
| 協作友善度 | 高 - Diff 乾淨，非工程師也能讀能改 | 較低 - 標記雜訊讓非技術同事的審閱變得吃力 |
這張表的結論
規律很明顯：只要瓶頸在「人要寫、人要讀」，Markdown 全面獲勝；只要瓶頸在「對最終輸出的控制」，HTML 全面獲勝。兩邊都沒有壓倒對方，這正是 Markdown 問世二十年後，兩者依然並存共榮的原因。
最被低估的那一列
是協作。Markdown 的 diff 直接顯示哪一句話改了；HTML 的 diff 則是同一句話被標記包住，審閱的人得自己挖出來。一份文件庫如果同時有設計師、客服主管和兩位工程師在改，這個差別就決定了團隊以外的人會不會願意動那個檔案。
Markdown 的主場、HTML 的主場 - 以及混搭絕招
這些情況請用 Markdown
- 做會議記錄，或經營個人知識庫。
- 寫專案文件或團隊 wiki。
- 檔案是 GitHub 或 GitLab 上的 README。
- 文章要放進 Hugo、Jekyll 或 Astro。
- 在 Reddit、Discord、Stack Overflow 留言。
在這些場景裡，速度與可讀性天天都在回本；而它的限制也永遠咬不到你，因為版面本來就由平台決定。這些地方多半跑的是 GitHub 風格 Markdown（GFM），在原始語法之上加了表格、待辦清單與刪除線。
這些情況請用 HTML
- 你在做多欄式的到達頁。
- 頁面需要含輸入框和按鈕的表單。
- 樣式必須精準到指定 class 與屬性。
- 你要嵌入影片播放器或地圖。
- 這段標記活在網頁應用程式裡面。
Markdown 根本沒有 <form>、<video> 或 CSS 網格的語法。它也不該有，那不是它的工作。
新手最常漏掉的混搭絕招
你其實很少需要二選一。Markdown 從設計之初就允許直接內嵌 HTML。所以你可以用舒服的 Markdown 寫完 95% 的頁面，只在需要的那一段切成 HTML：一張置中的圖片、一個 <details> 摺疊區塊、表格儲存格裡的換行。這種寫法在各地的 README 與技術部落格早就是標準做法。最實用的內嵌 HTML 片段，我們的Markdown 語法參考表都整理好了。
什麼時候用 Markdown，什麼時候用 HTML
實務上，只要知道該問什麼，這個決定兩秒就能做完。以下是最常遇到的情境與答案：
| 情境 | 該用 | 原因 |
|---|---|---|
| README 檔案 | Markdown | GitHub、GitLab、npm 都會自動渲染 .md，手寫 HTML 反而礙事 |
| 部落格文章 | Markdown | 內容以文字為主，靜態網站產生器會自動幫你編譯成 HTML |
| 專案文件 | Markdown | 版本控制的 diff 乾淨，非工程師也能改一頁而不弄壞它 |
| 會議記錄 | Markdown | 快到可以邊聽邊打，不渲染也好讀，待辦清單直接變成行動項目 |
| 電子報 | 兩者都用 | 用 Markdown 起草再匯出 HTML - 郵件軟體至今仍需要行內樣式與表格版面 |
| 到達頁（Landing Page） | HTML | 多欄版面、主視覺區塊、按鈕與追蹤程式碼都需要真正的標記 |
| 網頁應用程式介面 | HTML | 互動元件、狀態與無障礙屬性都不在 Markdown 的詞彙表裡 |
| 資料輸入表單 | HTML | Markdown 沒有 <form>、<input>、<select> 或驗證的語法 |
| 學術論文 | Markdown | 寫一次，用 Pandoc 轉成 PDF、LaTeX 或 DOCX，引註與註腳都支援 |
| 聊天訊息 | Markdown | Slack、Discord、Teams、Stack Overflow 都接受；原生 HTML 基於安全會被移除 |
表格背後的那條判準
把「該用」那一欄由上往下讀，一條判準自然浮現：原始碼會被人讀，就寫 Markdown；唯一的讀者是瀏覽器，就寫 HTML。
文件、筆記、文章、README 都會被同事和未來的你以原始碼的形式閱讀。在那裡，原始檔好不好讀比版面控制力值錢。介面、表單、行銷頁面除了維護它的人以外沒人會看原始碼，所以 HTML 多打的那些字，換來的精準度才划算。
內嵌 HTML 到底是拿來做什麼的
「兩者都用」那一列不是和稀泥，那正是多數資深寫作者的做法。真正會一再用到的只有五件事：
- 複雜表格。需要合併儲存格，或要在儲存格裡塞巢狀清單。純語法在哪裡見底，表格指南標得很清楚。
- 嵌入內容。用
<iframe>放影片或地圖。 - 樣式化提示框。加了 class 的
<div>，用在單純的引用區塊不夠看的時候。 - 圖片尺寸。
沒有寬度參數，<img src="chart.png" width="480" alt="季度營收">才有。 - 摺疊區塊。一個
<details>，幾乎人人最後都會用上。
也請注意哪些東西不在清單上。程式碼範例永遠不需要 HTML，因為圍欄式區塊更好讀、還能標語言，理由在程式碼區塊語法那一頁；引註也不需要，Markdown 註腳會自己編號、自己產生返回連結。
混搭之前的兩個提醒
注意：部分渲染器會限制內嵌 HTML。GFM 會過濾 <script>、<style>、<iframe>，所以在自家部落格能用的嵌入碼，放進 GitHub README 會被無聲移除。
小提醒：區塊層級的 HTML 標籤前後，各留一行空白。少了它，解析器可能把 <div> 周圍的 Markdown 當成純文字處理，而且症狀跟原因看起來八竿子打不著。
真的難以抉擇時，預設選 Markdown。在編輯器裡把 Markdown 轉成 HTML 只要按一下；把手寫的 HTML 頁面還原成乾淨可編輯的文字，卻要耗掉一個下午。先從成本低的那一層開始，只有真正需要的部分才下沉。
我們的建議：用 Markdown 寫，用 HTML 出貨
就日常寫作而言，實務上的答案已經很明確：用 Markdown 起草，需要時再匯出成 HTML。工作過程中你享有 Markdown 的速度和乾淨的版本控制 diff，要發佈的那一刻又能拿到符合標準的 HTML。
兩者都學的成本很低。Markdown 一個下午就上手；混搭時值得認識的那幾個 HTML 標籤 - <br>、<details>、可設定寬度的 <img>、<sup> - 再花一個下午就夠。
完整流程長這樣
- 打開免費的 MD Editor，一邊寫，一邊讓即時預覽確認每個元素的效果。
- 匯出 .md，保留一份可繼續編輯的純文字母版。
- 匯出 .html，下載一個含樣式的獨立網頁。
- 或按「複製 HTML」，直接取得渲染後的原始碼，貼進 CMS 或電子報工具。
整個轉換都在你的瀏覽器本機完成，寫的內容絕不會被上傳。如果這份文件要進的是程式碼儲存庫而不是網站，那就連匯出都免了：GFM 原始檔本身就是交付物。
這種分工為什麼站得住腳
用為人類設計的格式寫一次，讓機器產出為瀏覽器設計的格式。這種分工正是 Markdown 被發明出來的初衷，也是為什麼「Markdown 對決 HTML」從頭到尾都不是一場真正的對決。
相容性資料驗證日期
常見問題
Markdown 可以取代 HTML 嗎？
不行 - 它是 HTML 最常用子集的速記法。每份 Markdown 文件在瀏覽器顯示之前都會先轉成 HTML，所以 Markdown 是依賴 HTML，而不是取代它。遇到 Markdown 表達不了的結構，就直接寫 HTML，而且通常可以直接內嵌在同一個檔案裡。
Markdown 檔案裡可以混用 HTML 嗎？
可以。Markdown 從設計上就明確允許內嵌原生 HTML，多數渲染器（包括 GFM）都支援。常見用法有：在表格儲存格內用 <br> 換行、用 <details> 做摺疊區塊，以及需要控制圖片寬度時改用 <img> 標籤。
完全的新手應該先學哪一個？
毫無疑問先學 Markdown - 一小時內就能開始產出，而且筆記軟體、GitHub 和各大論壇用的都是它。從我們的 Markdown 指南開始即可。之後若要做網頁再學 HTML，觀念會自然銜接，因為你早已理解標題、清單和連結的概念。
怎麼免費把 Markdown 轉成 HTML？
把文字貼進或直接寫在 MD Editor，點 .html 下載含樣式的獨立檔案，或點「複製 HTML」把渲染後的原始碼複製到剪貼簿。轉換完全在你的瀏覽器內執行 - 不上傳、免帳號、零費用。
Markdown 和 HTML 是同一種東西嗎？
不是，它們是兩種不同的語言，只是最後會走到同一個地方。HTML 有數百個標籤，能完全掌控結構、版面與樣式；Markdown 只有十來個標點符號，由轉換程式把它們變成那些標籤中最常用的一小部分。這是刻意的取捨：功能少一點，打字量少很多，而且原始檔照樣讀得懂。那十來個符號能涵蓋多少東西，Markdown 完整指南裡看得最清楚。
Markdown 可以排成兩欄嗎？
不行，Markdown 完全沒有分欄或版面配置的語法，因為它只負責標記結構，長什麼樣子交給渲染器決定。要把內容並排，只能在檔案裡插一張 HTML 表格，或是用某個平台專屬、換個地方就失效的擴充語法。當你開始需要排版，那通常就是這份文件已經超出 Markdown 適用範圍的訊號；如果你真正想要的其實是列與欄的資料，表格指南裡有可攜的做法。
延伸閱讀
立即使用編輯器
立即使用編輯器