內容會上傳到伺服器嗎？
不會。整理原始碼、算繪預覽、富文字轉換和下載全部在瀏覽器本機透過 JavaScript 完成，頁面沒有後端介面，也不會把你貼上的內容傳送到任何伺服器。適合處理還沒發布的稿子和內部文件。頁面載入完之後斷開網路，工具照常可用，這是最直接的驗證方法。
這個詞容易被理解成兩件事。一件是把 .md 算繪成排好版的樣子看，那屬於閱讀，用MD 檔案線上開啟；另一件是把原始碼本身寫規範，比如該空行的地方補上空行、該對齊的表格對齊。這一頁做的是後者：進去是 Markdown，出來還是 Markdown，只是排整齊了。如果你的目的是把它交給別人看，需要的多半是Markdown 轉 Word / PDF。
Markdown 有幾個空白敏感的地方，寫錯了不會報錯，只會悄悄算繪成別的東西。最常見的是清單緊貼在上一段文字下面沒有空行，很多算繪器會把整個清單當成普通段落的續行，符號原樣顯示出來；標題的 # 後面漏了空格也是同類問題，在 GitHub 上不生效，在某些編輯器裡卻正常。這類毛病在原始碼裡看著沒問題，換個地方開啟才發現版沒了。補空行這一項修的就是它，屬於「改對了」而不是「改好看了」。
中文和英文、數字緊挨著的時候加一個空格，是中文技術寫作裡通行的排版習慣，理由是漢字是方塊字、拉丁字母不是，不留空隙時兩邊會擠在一起。工具按這個規則處理，同時把中文後面誤用的半形逗號、句號、問號換成全形。有兩個地方故意不動：程式碼區塊和行內程式碼裡的內容一個位元組都不改，否則 my_var_name 這種識別字會被改壞；中文.md 這樣後面跟著字母的句點也不會被當成句號，只有真正處在句末的才轉。英文文件把「中文排版」那兩項關掉即可。
從這些地方複製內容時，剪貼簿裡除了純文字還帶著一份 HTML，標題、清單、表格、粗體這些結構都在裡面。所以貼上時把它轉成 Markdown 是一次確定的轉換，不是根據文字長相去猜。反過來，純文字貼進來不會被自動加上 # 和 -：那種猜測經常猜錯，而猜錯的代價是你得再手工改回去。只想要純文字的話按 Ctrl+Shift+V，或者把「貼上」那一項的勾去掉。
整理原始碼是純粹的文字處理，算繪預覽也可以完全在瀏覽器裡做，沒有一步必須交給伺服器。這不只是隱私上的好處：沒有上傳就沒有檔案大小限制、沒有排隊、沒有次數限制，頁面載入完之後斷網照樣能用。還沒發布的稿子、內部文件、寫了一半的技術方案，都不必先交給一個你不認識的伺服器。
不會。整理原始碼、算繪預覽、富文字轉換和下載全部在瀏覽器本機透過 JavaScript 完成，頁面沒有後端介面，也不會把你貼上的內容傳送到任何伺服器。適合處理還沒發布的稿子和內部文件。頁面載入完之後斷開網路，工具照常可用，這是最直接的驗證方法。
不會。用 ``` 或 ~~~ 圍起來的程式碼區塊，以及用反引號包起來的行內程式碼，內容一個位元組都不動 —— 不加空格、不改標點、不動縮排、不重排。這是硬約束，否則 my_var_name 會被當成斜體、a,b 裡的逗號會被換成全形，程式碼就不能跑了。連結裡的網址同理，只有連結的文字部分會被處理。
不能，這是有意不做的。從 Word、網頁、飛書、語雀複製過來的內容剪貼簿裡帶著 HTML，標題和清單是明確寫在裡面的，轉成 Markdown 是確定的事；而一段純文字裡哪行是標題、哪幾行是清單，只能靠長相去猜，猜錯了你還得手工改回來，比自己敲 # 更費事。所以這一頁只在偵測到帶格式的內容時才自動轉換。
最常見的原因是清單緊貼在上一段文字下面，中間沒有空行。GitHub 按 CommonMark 解析，這種寫法會把清單當成上一段的續行，於是 - 原樣顯示出來。另一個常見原因是標題的 # 後面漏了空格。把內容貼進來點「格式化」，「標題、清單、程式碼區塊、表格前後補空行」和「標題統一用 # 寫法」這兩項就是修這個的。
不是規範要求，是中文技術寫作裡通行的排版習慣，多數中文技術文件、多數團隊的寫作規範都這麼做。它不影響 Markdown 的解析，純粹是閱讀體驗。如果你的專案不這麼要求，或者文件本來就是英文的，把「中文排版」那兩項的勾去掉即可，其餘整理照常進行。
勾了「有序清單重新編號」就會改成 1. 2. 3.。全寫 1. 是一種常見寫法，算繪結果和依次編號完全一樣，好處是中間插入一項時不用改後面所有的號。如果你就是想保留這種寫法，把這一項關掉。另外要注意：中間只隔一個空行的兩段有序清單，按 CommonMark 仍然算同一個清單，所以編號會連著往下走，不會從 1 重新開始 —— 想真正斷開需要在中間插入一段文字或別的內容。
不會。Markdown 裡行尾的兩個空格表示強制換行，工具認得這個寫法並保留下來；三個以上的會收成正好兩個，而不是當成手滑一併刪除。其餘情況下的行尾空白才會被清掉。如果你更習慣用反斜線換行，那種寫法本來就不受影響。
可能會。對齊靠的是給儲存格補空格，而中文字元在等寬字型裡佔兩個字元寬 —— 工具按這個規則算，所以在 VS Code、Typora 這類等寬顯示的地方是齊的。如果某個編輯器用非等寬字型顯示原始碼，看起來就不齊。這只影響原始碼的觀感，算繪出來的表格永遠是對的，因為算繪只看豎線的位置，不看空格數量。
那一頁是純閱讀器：拖進去直接看排好版的樣子，不編輯、不匯出，適合收到一份 README 想讀一遍。這一頁會改寫你的原始碼，輸出還是 Markdown。想看用MD 檔案線上開啟，想整理用這一頁。
在這一頁點「複製」，然後貼到Markdown 轉 Word / PDF裡匯出，或者先「下載 .md」再把檔案拖到那一頁。分成兩頁是因為兩件事的產物不一樣：這一頁給你 Markdown 原始碼，那一頁給你能直接發給同事的 .docx 或 .pdf 檔案。
表格支援，會按欄寬對齊。任務清單（- [ ]）、刪除線、註腳這些擴充語法會被原樣保留，不會被破壞，只是沒有針對它們的專門整理規則。預覽用的是 GitHub 風格的解析器，所以表格和任務清單在右邊能正常顯示。
整理本身是純文字處理，幾萬行也很快。可能變慢的是右邊的即時預覽 —— 它要為每個元素產生 DOM。如果文件特別大又覺得卡，可以先把關心的部分截出來處理。輸入停止約 0.2 秒後才會重新算繪，正常打字不會每敲一個字就重排一次。