To Markdown 免費文件轉 Markdown 實測：三種檔案的真實輸出與檔案流向

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把同一份內容分別做成 Word 檔和 PDF、再另外準備一張圖片，丟進 To Markdown 會得到三種不太一樣的結果：標準樣式的 Word 轉出完整的標題、超連結和管線表格；PDF 的標題抓得準，清單和表格卻併成一行；輸出最漂亮的反而是圖片，兩欄表格一字不差，但那條路線的引擎標籤寫著 zhipu-vision，圖片是交給視覺模型辨識的。這篇把三次轉換的實際輸出、檔案流向和官方宣稱的落差攤開來看。

To Markdown 是 to-markdown.com 上的一個免費線上轉換工具，免註冊、開網頁就能用，主打把 PDF、Word、PowerPoint、Excel、圖片和網頁轉成 Markdown。站方另外經營 pdf、word、ppt、excel、image、text、youtube 等同品牌的子網域工具，主站一次收全部格式。

Pin

同一份內容，三條路線的實測怎麼做

我準備了一份固定內容的測試文件，裡面有一級和二級標題、兩條項目符號、一個外部超連結、一張兩欄表格，再加一段繁體中文段落（含引號、刪節號和日期）。這份內容做成三個檔案上傳：一份用標準 Heading 樣式建立的 Word 檔、一份 macOS 內建工具轉出的 Word 檔、一張瀏覽器列印的 PDF。圖片路線另外用繪圖程式合成一張內容不同的英文圖片，放了標題、兩行狀態文字、日期和兩欄表格，測的是它讀圖的能力。全部走一般訪客的網頁流程，不上傳帳號、不動 API 金鑰，同時側錄瀏覽器進出的網路請求。

繁體中文是先講結論：三次帶中文的轉換（兩份 Word 與 PDF）裡，引號「」、刪節號……和「2026 年 9 月 22 日」這類內容全都原樣保留，沒有簡體化或亂碼；另外兩次（圖片與網址）的測試內容本身不含中文。對以中文文件為主的使用者來說，這關是過的。

Word 路線：標準樣式轉得完整，輸出前要再清一次

標準樣式的 Word 檔是三條路線裡轉得最完整的。API 回傳的 Markdown 長這樣：

# **Q3 Launch Plan**

## **Owner Assignments**

Prepare pricing review

Draft customer announcement

Reference: [pricing page](https://example.com/pricing)

|  |  |
| --- | --- |
| Item | Owner |
| Pricing review | Ming Wang |
| Announcement | Li Chen |

# **台灣繁體中文測試段落**

這是用來測試繁體中文轉換的段落：標點符號「引號」、刪節號……以及數字 2026 年 9 月 22 日。

第一項工作清單

第二項工作清單

標題、超連結、表格三個關鍵結構都活了下來：連結的文字和目的地成對保留，表格轉成標準管線語法。但輸出有兩個小毛病。表格最上面多出一列空表頭（| | |），貼進筆記軟體會多一列要刪；標題後面殘留粗體符號，# **Q3 Launch Plan** 這種寫法在大部分渲染器看起來正常，語法上卻是重複標記。對照站方自己發布的轉換範例，空表頭列同樣出現在他們的展示輸出裡，品質基準頁也把「多出空表格標頭列」列為已知檢查點，所以這是常態行為而非偶發，拿到輸出後花幾秒清一下就能用。

Pin

這裡的「標準樣式」值得展開講，因為它是 Word 路線成敗的分水嶺。文件裡的標題要是用樣式功能（Heading 1、Heading 2）標出來的，轉換器才認得出層級；很多人習慣把文字手動放大加粗當標題用，這種檔案在轉換器眼裡就只是一段粗體文字。同樣道理，項目符號要用真正的清單功能，不要自己打星號或圓點。

來源檔的樣式衛生會直接影響結果。另一份用 macOS 內建工具轉出的 Word 檔（內容相同，但樣式定義不正規）轉出來就整個退級：標題變成純粗體文字、項目符號變成實心的 • 字元、超連結只剩文字沒有網址、表格攤成一行一行的段落。辦公室裡由各種軟體輾轉產生的 Word 檔不少，拿到輸出後最好先對著原稿檢查標題層級。

同品牌的簡報和試算表各有子網域，官方說明寫得誠實：PowerPoint 轉出來是線性的大綱文字，視覺版面、圖表和動畫不會保留；Excel 的儲存格資料會轉成 Markdown 表格。這兩條路線這次沒有實測，定位上當作「抽文字內容」的工具比較安全。

PDF 路線：標題抓得準，清單和表格併成一行

瀏覽器列印的數位 PDF（有文字層、非掃描）轉出來，標題的判斷是準的，一級二級都對應到正確的 # 層級。問題在標題以下的結構：

Prepare pricing review Draft customer announcement Reference: <u>pricing page</u> **Item Owner** Pricing review Ming Wang Announcement Li Chen

兩條項目符號、超連結和整張表格被併成同一行，連結變成 HTML 的底線標籤、沒有網址，表格的欄位邊界全部消失。閱讀順序沒有錯亂，字也沒有漏，但拿到手的基本是一串要手動斷行、手動重建表格的文字。站方在首頁說明也寫明複雜版面需要事後檢視，這條路線適合「只要文字內容」的場景，不太適合要結構的場景。

掃描版 PDF 有另一條規則。官方說明寫得清楚：只有文字層的數位 PDF 走一般轉換，純掃描的頁面要改走圖片 OCR 的流程（把頁面當圖片處理）。所以手上如果是紙本掃出來的 PDF，一般轉換拿不到文字內容（這次未實測掃描檔，依官方說明推斷），要改走它的圖片 OCR 流程，或考慮以 OCR 為主的自架方案。

轉換速度倒是不用擔心。官方首頁標示多數檔案幾秒內完成，這幾次實測也沒有感受到明顯等待。

圖片路線：輸出最完整的是它，引擎是視覺模型

最出乎意料的是圖片。一張排版乾淨的合成 PNG，畫了標題、兩行狀態文字、日期和兩欄表格，轉出來是三條路線裡品質最高的：

# Weekly Status

Build passed on staging cluster  
Security review scheduled  

Date: 18 August  


| Owner   | Task             |
|---------|------------------|
| Ming Wang | Fix retry logic |
| Li Chen  | Update runbook  |

標題、清單、表格全部到位，人名和日期這些關鍵字元一字不差。原因寫在 API 回應的 metadata 裡：這條路線的引擎標籤是 zhipu-vision，並且標記 processed_with_llm: true。也就是說，圖片不是走傳統 OCR，而是交給智譜的視覺模型去讀。視覺模型擅長猜版面結構，所以截圖裡的表格反而能轉成完整語法；代價是辨識結果帶機率性，站方自己在品質基準頁也提醒手寫、公式、低解析度都需要逐張核對，而且你的圖片會送到這個模型處理。這次的測試圖是排版乾淨的合成圖，比真實螢幕截圖單純，結果本來就偏向最好情況。

站方對品質這件事做的功比一般免費工具多，值得記一筆。它有一個公開的品質基準頁，版本 1.0，發布了三個可重製的測試檔（Word、PowerPoint、圖片各一）和一份可重複執行的評測方法：來源凍結、原始輸出保存、逐項比對結構與關鍵字元，結果只標「通過、需整理、無對應、關鍵失敗」四級，並且明講不把結果平均成單一準確率。它甚至公開承認 Word 轉換不保留內嵌圖片、註解、頁首頁尾和追蹤修訂。一個把自家缺陷寫成文件的工具，比把「完美保留」寫在行銷頁的工具可信得多。

檔案去哪了：全程上伺服器，圖片再交給視覺模型

這個工具的轉換不在瀏覽器裡做。從頁面程式的流程看，按下轉換時會先向 /api/web-session 要一個簽名的 session，再把整個檔案以表單上傳到 /api/v1/convert/file，伺服器轉完回傳 JSON。換句話說，文件內容會完整離開你的電腦，進到站方伺服器，圖片類再送到視覺模型。API 文件也設計成前後端分離：正式的 API 走 api.to-markdown.com 子網域、用 Bearer 金鑰，網頁版靠 session cookie、不把金鑰放進前端程式碼，這個切割在資安上是及格的設計。

隱私政策寫了三件事：上傳過程加密、暫存檔在處理完成後刪除、檔案不用於廣告。隱私政策沒有提到的，是圖片 OCR 由第三方視覺模型處理這件事（從回傳的引擎標籤才看得到）；廣告則只用「Google 與其廣告夥伴可能使用 cookies」一句概括帶過，實測側錄看到的第三方 cookie 同步對象沒有被點名（下一節談）。刪除的實際時機從外部無法驗證，這幾句要當成官方說法而非已查證的事實。

首頁掛著「Private by Design」的標語，旁邊跑的是 Google AdSense 廣告。實測的連線紀錄裡，頁面除了 Google 廣告網域，還出現 AdSense 需求夥伴的 cookie 同步請求（其中一次側錄見到 StackAdapt、AppLovin 和 Temu 的廣告網域）。流量分析用的是自架 Umami（腳本網域與隱私政策宣稱吻合）。廣告與 cookie 同步是 AdSense 網站的常態，拿機密文件來轉之前，把「檔案上伺服器、圖片送視覺模型、頁面掛廣告」三件事一起放進考量就好。

首頁宣稱與實測行為的落差

首頁寫「More formats: CSV, JSON, XML, ZIP, EPUB, EML, MSG, MP3, and WAV」，把音檔和郵件檔也列進去。實際丟一段 WAV 上傳，伺服器直接回 400，錯誤碼 UNSUPPORTED_FORMAT；檔案選擇器的副檔名白名單裡也沒有 mp3、wav、eml、msg、zip。文件頁的支援格式清單和實際行為一致，等於首頁那句多寫了。

免費的邊界：單檔 10MB、無批次、API 要另外談

免費使用的邊界算清楚。單檔上限 10MB；沒有批次，官方 FAQ 直接寫「Current APIs process one file per request」；要程式化整合的話，API 文件列了完整的 REST 端點（同步、非同步佇列、網址、YouTube、OCR 各一），速率限制從每小時 30 到 120 次不等，但 API 金鑰不開放自助申請，要走「Discuss API access」的聯絡表單，填使用情境和預估量。

站方自己定的客群也值得知道：它發布了三篇工作流指南，分別講轉出來的 Markdown 怎麼進 RAG 檢索流程、怎麼整理進 Obsidian 知識庫、怎麼變成 MkDocs 或 Docusaurus 的文件站。整個產品的想像使用者是把文件搬進知識系統的人，不是要還原排版的人，這個定位跟前面三條路線的實測結果是一致的。

網址轉換這條我實際測了：丟一個公開網頁進去，回傳正常的 Markdown（引擎標籤 markdownify），標題和連結都對。YouTube 字幕路線這次沒有實測，站方說明只取既有字幕軌、不加摘要和時間戳。

輸出拿法有兩種：介面上直接複製整段 Markdown，或下載 .md 檔；也有預覽分頁可以先看渲染結果。要注意它不會幫你存歷史紀錄，換一個檔案轉換，前一次的結果就不在了，要留的話當場下載。

經營者是誰，條款寫到什麼程度

網站頁尾的 GitHub 和 X 連結都指向 UllrAI，一家新加坡的 AI 產品工作室（GitHub 組織頁標明的所在地），官網自稱推出過九個以上的 AI 工具，To Markdown 沒有公開原始碼。條款頁的聯絡地址欄還留著範本佔位字串「[Your Company Address]」，條款和隱私政策兩頁的更新日期在我造訪當天都顯示為 2026 年 9 月 22 日。聯絡信箱有 support 和 contact 兩組，網域就是 to-markdown.com 本身。對一般個人使用影響不大，若要拿去做商業流程的整合，授權與營運主體的成熟度要先自己評估。

把它放進工具箱的心智模型很簡單：這是一個廣告支撐的雲端轉檔服務，用「免費免帳號」換你的檔案過境它的伺服器，同時用公開的品質基準和誠實的邊界文件建立可信度。它不是本地工具，也不是開源專案，拿這三個身分去期待它都會落空。

適合誰，不適合誰

適合的場景很明確：把不敏感的 Word 或 PowerPoint 草稿快速搬進 Markdown 筆記或文件庫，來源檔用標準樣式寫的話輸出可直接用；把小張截圖裡的表格抽出來變成管線語法，這條路線的輸出品質最好。臨時要把某個公開網頁存成 Markdown 筆記也行。

不適合的也一樣清楚。機密或敏感文件不該丟，檔案會完整上伺服器、圖片會送視覺模型；需要逐字可靠的正式文件（合約、報表數字）要人工核對，視覺模型和版面解析都帶機率性；音檔需求目前直接不用考慮；企業批量流程在聯絡到 API 金鑰之前走不動。

想要類似能力但把處理留在自己這邊的，可以參考站上先前的整理：Zerox OCR 同樣用視覺模型讀文件但走開源自架、模型和金鑰自己掌握；PDF2MD 和 OCRFlux 是自架的 PDF 轉 Markdown 路線。方向相反、要把 Markdown 轉回 Word 的看 MarkdowntoWord；對線上轉檔的資料流向想先有心理準備的，奇客 PDF 轉 Word 的實測記了同一類工具的隱私邊界。

To Markdown 值得放進書籤的理由是免費、免帳號、繁中內容處理乾淨，Word 和截圖兩條路線的輸出在水準之上。用的時候記住兩件事就夠：來源檔的樣式愈標準、輸出愈完整；檔案內容會離開你的電腦，敏感的東西換自架路線。