URL 轉 Markdown 轉換器：公開網頁

如何操作

如何把網頁轉成 Markdown

可以貼上什麼

任意公開的 http(s) 頁面 —— 文章、文件、部落格文章
需要登入或位於付費牆後的頁面無法抓取
頁面在我們的伺服器上抓取，不會執行其 JavaScript
無需帳號即可試用：單檔案最大 10 MB、25 頁，每小時 3 次、每天 10 次轉換

URL 轉 Markdown 轉換器：把網頁 URL 轉成 Markdown 視窗

為什麼使用

為什麼使用這款 URL 轉 Markdown 轉換器

網頁是寫給瀏覽器看的。Markdown 是寫給人看、給模型讀的。這款轉換器會找出頁面裡承載含義的部分，保留其結構，把網站的邊角裝飾留在外面。

只留正文，不留整頁

多個擷取器會分別讀取頁面，保留文章內容最多的結果勝出，因此選單、Cookie 提示條、頁尾和相關文章欄都不會出現在 Markdown 裡。

能留存下來的結構

標題、列表、表格和程式碼塊都以 Markdown 形式呈現，頁面裡每個相對連結和圖片路徑都會被改寫成完整 URL，離開原頁面也能使用。

JavaScript 頁面也能渲染

當初始 HTML 只是一個空的應用外殼時，頁面會先在無頭瀏覽器裡渲染，再轉換渲染後的內容。

免費試用，無需登入

無需帳號即可預覽並複製 Markdown，每小時最多 3 次轉換、每天 10 次。登入後可下載 .md 檔案。

有禮、表明身分的抓取器

每次請求都會用有文件記錄的 user agent 表明身分，網站擁有者可以阻擋它——見文件裡的抓取器頁面。

與 API 同一套引擎

本頁的轉換器和 POST /v1/convert/url 執行同一份程式碼，所以指令碼每次呼叫最多可轉換 20 個 URL。

問題所在

為什麼線上頁面對模型來說很嘈雜

頁面很嘈雜

線上網頁把內容埋在導航、廣告、橫幅和指令碼之下——這些文字的總量往往是文章本身的好幾倍。

標記很亂

手寫和生成的 HTML 很少能幹淨地對應為可讀結構。

AI 需要的是文章

RAG 和 agent 想要的是文章本身，而不是它周圍的頁面外殼——而有些頁面只有在 JavaScript 執行之後才會顯示文章。

網頁轉 Markdown：複製貼上後的錯亂文字與乾淨的 Markdown 結構對比

保留什麼

這款 URL 轉換器抓取什麼

服務端抓取: 頁面在服務端被抓取，會先請求 Markdown、再請求 HTML；只有網站自己的 Markdown 通過品質檢查時才會使用它。無需瀏覽器外掛或本機工具。Source: RFC 9110: HTTP Semantics
正文擷取: 多種擷取方式——可讀性評分、樣板內容偵測、文字密度分析，以及頁面自身的 main 或 article 元素——會相互競爭，保留結構和正文最多的一種勝出。文件產生器、GitHub、Wikipedia 等知名網站則使用網站專屬規則。Source: HTML Living Standard: the main element
JavaScript 渲染的頁面: 空的應用外殼會先在無頭瀏覽器裡渲染，瀏覽器等待頁面穩定後，把渲染出的 DOM 交給同一套擷取流程處理。只有點擊或捲動後才出現的內容不會被擷取。Source: HTML Living Standard
公開頁面、大小與身分: 只支援公開可存取的 URL：位於身分驗證、付費牆或登入牆之後的頁面無法抓取。抓取的頁面受回應大小限制，抓取器的 user agent 記錄在 /docs/fetcher。Source: product pipeline

示例：透過 URL 抓取 markitdown.ai 部落格文章· https://markitdown.ai/blog/why-pdfs-break-llms

# Why PDFs break LLMs — and what clean Markdown fixes _Published 2026-06-12 · The markitdown.ai team_ > A PDF that looks perfect to a human often falls apart the moment a model reads it. Here's what goes wrong, and why converting to clean Markdown first makes downstream AI far more reliable. A PDF renders perfectly for a human and falls apart the moment a model reads it. The page you see — columns, tables, headers, footnotes — is a *visual* arrangement, not a logical one. When you pull raw text out of it, that visual order rarely survives, and whatever you feed a language model is only as good as the text it actually receives. ## What actually goes wrong When teams pipe documents straight into an LLM or a retrieval index, a few failure modes show up again and again: - **Reading order breaks.** Multi-column layouts interleave. A two-column page becomes "line 1 left, line 1 right, line 2 left, line 2 right…", so a sentence a human reads top-to-bottom arrives at the model scrambled.- **Tables collapse.** Copy-paste turns a table into a loose run of numbers. The relationship between a header and its cell — the entire point of a table — is gone.- **Headings disappear.** The visual hierarchy (this is a section, this is a subsection) is encoded as font size and weight, not structure. Strip the styling and you get one undifferentiated wall of text.

使用場景

網頁轉 Markdown 的使用場景

從 AI agent 到內容遷移，把網頁轉換成 Markdown 是許多工作流都依賴的一小步。

AI 與 LLM 流程

把文章和文件作為帶完整標題的乾淨文字餵給 RAG 索引、agent 工具和提示詞，而不是原始 HTML。

研究與筆記

把來源儲存為 Markdown，用於引用、批註或留在 Obsidian 或筆記倉庫裡——原始連結依然在位。

內容團隊

把文章和幫助中心頁面從一個 CMS 遷到另一個，或把參考資料拉進基於 Markdown 的文件站。

開發者

在你已有的攝取任務和爬蟲裡呼叫 API，拿到與瀏覽器轉換器顯示的同一份 Markdown。

網站轉 Markdown：把一個 Markdown 檔案接入 RAG 索引、提示詞與筆記

API

專為開發者的 URL 轉 Markdown API

要從程式碼轉換頁面？把一個 URL——或 urls 陣列裡最多 20 個——發到帶 API 金鑰的 POST /v1/convert/url。把 render 設為 auto、force 或 skip 可以控制是否渲染 JavaScript，把 frontmatter 設為 true 可以把頁面標題、作者和發布日期放進 YAML front matter。頁面在等待視窗內完成時，Markdown 會在同一個回應裡返回；否則你會拿到一個可輪詢的轉換，或它完成時的一個 webhook。API 存取在付費套餐上提供。

閱讀 API 指南

curl -X POST https://api.markitdown.ai/v1/convert/url \  -H "x-api-key: mdai_…" \  -H "content-type: application/json" \  -d '{"url":"https://markitdown.ai/blog/why-pdfs-break-llms","frontmatter":true}'

指南

檢查輸出結果

把 URL 轉 Markdown 的輸出與你提交的公開頁面對照。轉換器會保留正文，去掉導航、Cookie 提示和頁尾連結，但對沒有明確文章結構的頁面——產品頁、到達頁、帶很多推薦欄位的首頁——仍可能丟掉一個側欄，或保留一段你並不想引用的內容。在為結果建立索引之前，先核對開頭和結尾段落與原頁面是否一致。用 JavaScript 建構內容的頁面會先在瀏覽器裡渲染；只有點擊、捲動或登入後才載入的文字仍然無法擷取。如果某個網站已經為請求 Markdown 的用戶端提供了自己的 Markdown，轉換器會在它通過品質檢查時直接使用；如果它看起來像整站選單或封存傾印，則會回退到 HTML 頁面。把來源 URL 與 Markdown 一起保留，讓讀者能回到原始頁面。

保留來源上下文

在你自己的工作流裡，把提交的 URL 和你的檢索日期與 URL 轉 Markdown 的結果一起保留。公開頁面在你轉換之後可能改動，後來的訪客可能看到修改過的段落。開啟 front matter 後，結果開頭會帶上來源 URL、canonical URL、標題，以及頁面聲明了的作者、發布日期、描述、網站名稱、語言和主圖——這些都讀自頁面的 meta 標籤、結構化資料和署名資訊。這些欄位只是複述頁面自己聲明的內容；如果你的研究依賴它們，請在來源處核對。API 的 metadata 欄位則不同：它只攜帶你自己提供的上下文。在引用一張表或一段話之前，先與頁面對照，並保留足夠的周邊上下文以免改變含義。Markdown 讓網頁內容更易複用；它並不確立該頁面是否準確，也不確立你是否有權轉載它。

儲存的 HTML 與 URL

當你已經擁有需要處理的確切頁面快照時，選擇 HTML 轉換器。當公開可存取的地址就是本次轉換的輸入時，選擇 URL 轉 Markdown。這是兩種相關但來源控制不同的工作流：儲存的檔案固定了你提交的輸入，並會被完整轉換；而 URL 取決於網站在請求時返回什麼，並會被壓縮為正文內容。兩條路徑都不會繞過存取限制。如果某個網站拒絕抓取器或要求登入，請使用你有授權透過合適工作流獲取的材料。不要反覆重試一個無法存取的 URL，彷彿再轉換一次就能獲得存取權限。

LLM 研究

研究者貼上的是一個來源，而不是一個檔案。這個轉換器抓取你提交的 URL，保留文章或文件正文，並返回你可以引用、切分或放進筆記庫的 Markdown，其中的連結依然可以開啟。當伺服器返回一個空外殼時，它會渲染 JavaScript 頁面；它不會登入付費牆。

只支援公開可存取的 URL。
抓取器會表明自身身分；運營方可以拒絕該 user agent——見 /docs/fetcher。
儲存的 HTML 檔案屬於 /html-to-markdown，不屬於這裡。

URL 轉 Markdown 轉換器常見問題

URL 轉 Markdown 轉換器是怎麼工作的？

URL 轉 Markdown 會抓取你貼上的公開頁面，保留其正文內容，並轉換成帶完整 URL 連結的 Markdown——無需上傳檔案。需要 JavaScript 的頁面會先在瀏覽器裡渲染。

它會從線上頁面裡去掉廣告和導航嗎？

對有明確正文區域的頁面可以。URL 轉 Markdown 會保留文章、文件正文或討論串內容，去掉選單、Cookie 提示條和頁尾；沒有單一正文區塊的到達頁或產品頁仍可能保留或丟失某個側欄，請檢查結果。

抓取的頁面有大小限制嗎？

公開轉換器對公開網頁生效。抓取的頁面受回應大小限制限制，過大時會被拒絕。

對登入後的頁面有效嗎？

無效。只支援公開可存取的 URL。位於身分驗證、付費牆或登入牆之後的頁面無法抓取。

依賴 JavaScript 渲染的頁面呢？

當初始 HTML 只是一個空外殼時，JavaScript 渲染的頁面會先在無頭瀏覽器裡渲染，然後像其它頁面一樣轉換。透過 API，把 render 設為 force 會始終渲染，設為 skip 則從不渲染。只有點擊、捲動或登入後才出現的文字不會被擷取。

可以一次轉換多個 URL 嗎？

把最多 20 個公開 URL 的 urls 陣列發到 POST /v1/convert/url。逐個追蹤檔案結果並處理非同步回應。見 /developers。

URL 轉 Markdown 免費嗎？

免費。無需帳號即可預覽並複製 Markdown，每小時最多 3 次轉換、每天 10 次；下載 .md 檔案需要登入。僅限公開網頁（不支援內部網路或私有 URL）。

轉換器保留哪些內容？

轉換器會保留正文中的標題、段落、列表、連結、圖片、表格和程式碼塊，相對連結會被改寫成完整 URL。指令碼、樣式、導航和頁尾會被丟棄；開啟 front matter 後，頁面標題、作者和發布日期會放在開頭。

有 URL 轉換 API 嗎？

有。可以透過 REST API 以程式設計方式透過 URL 轉換網頁。見 /developers。儲存的 HTML 檔案請改用 /html-to-markdown。

URL 轉 Markdown 轉換器