PDF 转 Markdown：留下结构，扔掉排版垃圾
PDF 本质上只是一份"墨水该落在页面哪里"的说明书，真的仅此而已。文件里没有"这是标题"、"这是表格" 之类的语义——只有摆在坐标上的字形，再加一个把它们渲染得井井有条的引擎。这也是为什么把 PDF 复制粘贴 进 ChatGPT 经常得到一团浆糊：模型收到的是一串字符流，所有视觉层级都被剥光了。
PDF 转 Markdown 做的就是把这套层级重建回来。字号和字重变成 # 和
## 标题，对齐的单元格网格变成竖线表格，项目符号变成列表项。你拿到的是一份 LLM 能真正
"导航"的文档，而不是一份只能靠猜的。把文件拖进上方的工具，几秒钟就出结果——免费、免注册、不存储
任何内容。
转换之后，究竟哪些东西能活下来
转换前值得先了解一下，这决定了你对结果该抱怎样的预期：
- 标题——根据相对字号和字重推断。字号体系统一的报告转出来非常漂亮；设计师主导、 每个小节样式都不一样的 PDF 就要乱一些。
- 表格——只要源文件有真实的行列对齐，就会重建为 Markdown 竖线表格。对财务报告、 规格表和数据附录来说，这是选 Markdown 而不是纯文本的头号理由。
- 列表——项目符号和编号条目保留嵌套层级，操作步骤和需求清单依然可读。
- 阅读顺序——双栏学术论文会被线性化为单一文本流。通常是正确的，但源文件里有 浮动边栏或引文框时偶尔会交错。
- 活不下来的——页面装饰。页眉、页脚、页码在 AI 场景里全是噪音，剥掉它们是功能， 不是损失。
选 Markdown 还是纯文本？直接给答案
文档的形态本身携带信息时，选 Markdown。分节论证的研究论文、带编号条款的合同、塞满 表格的年报、含代码块的技术文档——在这些场景里，结构就是信息。你问模型"第 7.3 条写了什么"， 它得先知道第 7.3 条是一个独立的单元。
只要散文本身、不要别的时，选 PDF 转文本—— 比如把语料喂给分类器、做关键词分析，或者送进任何一个见到语法字符就噎住的程序。在那些地方，Markdown 的竖线和井号纯属累赘。
本页顶部的切换按钮能在两种格式之间来回切，并且会把你已经选好的文件一起带过去——两个方向各转一遍 做对比，不用重新上传。
原生 PDF 与扫描件：为什么你的输出可能是空的
顶着同一个扩展名的 PDF 其实有两种，行为天差地别。
原生 PDF——从 Word、LaTeX、InDesign 或浏览器打印对话框导出的那种——内嵌了真实文本， 转换基本无损，而且快。扫描版 PDF 则是纸张的照片套了个 PDF 外壳，里面没有任何文字可提取， 只有像素。
判断只要两秒：打开 PDF，用鼠标去选一句话。文字能被高亮，就是原生文件，转换会很干净；整页只出现一个 选择框，那就是扫描件。扫描件请先跑 OCR——多数 PDF 阅读器内置"识别文本"功能——再来转换。多花一分钟， 输出质量却是天壤之别。
直接把 PDF 传给模型不就行了，何必转？
现在大多数聊天助手都能直接上传 PDF，所以这个问题问得很合理。但先转换仍然赢在三点：
- 你看得到模型看到的东西。直接传 PDF 得到一个糟糕的答案时，你分不清是模型推理 出了问题，还是提取环节把源文件搅烂了。Markdown 摆在你面前，这层含糊就不存在了。
- 发送前可以先编辑。删掉 40 页法律套话，只留下真正要紧的 3 页。更便宜、更快， 答案也明显更准。
- 它能组合。Markdown 文本可以直接放进系统提示词、RAG 管线、微调数据集或 git 仓库。 一个 PDF 附件哪儿都去不了。
输出下方的 token 计数器才是实用的部分。一份 60 页的报告大概落在 40,000 token 上下——长上下文模型 没问题，小模型就超预算了。粘贴之前就心里有数，总比从报错信息里发现要好。
大家实际拿它干什么
- 文献综述。把一摞论文全部转换、拼接 Markdown，然后让模型找出各篇在方法论上的分歧。 小节标题都还在，任何一条结论都能追溯回出处。
- 合同审阅。编号条款依然带编号，你可以针对具体义务提问，得到引用真实条款号的回答， 而不是转述。
- API 与供应商文档。不少企业级 SDK 的参考文档至今还是 PDF。转换之后，配上你的 GitHub 仓库文本，编程助手就能同时看到 规格和你的实现。
- 财务报表。靠的就是表格重建——行列完整时，模型才能跨季度比对数字。
- 讲义和教材。转换整章，先要总结，再用同一份材料生成练习题。
怎样拿到更干净的输出
- 如果这份 PDF 有文本格式的"兄弟版本"——论文的 HTML 版、报告导出前的 DOCX——直接转那个。推断 步骤更少，结构更好。试试 Word 转 Markdown 或 HTML 转 Markdown。
- 超大的 PDF 先拆再转。500 页的手册能转，但整块塞不进任何上下文窗口；只喂你真正关心的那一章， 答案会更好。
- 画成图片而非文字排版的表格无法重建——不做 OCR 谁也读不出来。表格对你重要的话，检查一下输出。
- 粘贴前扫一眼开头几百行。发现一个错乱的标题层级只要十秒钟，却能省掉一场和模型的糊涂对话。
常见问题
怎么在线把 PDF 转成 Markdown？
把 PDF 传到上方，Markdown 就出现在下面，可以直接复制，也可以下载成 .md。免费、免注册、单文件上限 50 MB。标题转回 # 层级，列表转回 - 符号，表格转成竖线表格，结构可以完整交给下一个读它的程序。
PDF 转 Markdown 能保住表格吗？
能，而且这正是选 Markdown 而不选纯文本的主要理由。表格会变成保留行列关系的竖线表格，模型被问"第三季度营收是多少"时，仍然分得清哪个数字属于哪个表头。同一张表压成纯文本，这层对应关系就再也找不回来了。
PDF 里的图片会怎么样？
插图、图表和照片不会带进 Markdown——输出的是文本层，不是素材包。如果某一页的关键信息在示意图里，就把那一页单独存成图片，走一遍图片转 Markdown，它能读出画面里渲染的文字。
有没有做 PDF 转 Markdown 的 Python 库？
有好几个——常见的是 pymupdf4llm、marker 和 docling，要在管线里批量处理一万个文件，它们才是正解。但它们也要虚拟环境、模型权重和 GPU 时间。你只有一份文档，还想在给 Claude 或 ChatGPT 发下一条消息前转完，一个浏览器标签页就赢了。
喂给 LLM 的话，PDF 转 Markdown 和转文本哪个更好？
文档有结构就选 Markdown。模型在海量 Markdown 上训练过，天生认得它的标题和表格写法，"总结第 4 节"之所以行得通，是因为第 4 节被明确标出来了。只有当你想把语法字符彻底清掉——主要是为向量化切块——才去用纯文本。
页面顺序和阅读流会被保留吗？
单栏文档的阅读顺序很可靠。双栏学术排版通常也能正确线性化，但引文框、浮动边栏和脚注块偶尔会落到段落中间——因为它们在源文件坐标里就位于页面中部。要拿去做精确的事情之前，值得先把输出扫一遍。
工具箱里的其他家伙
PDF 只是这里支持的十三种格式之一。不想挑具体页面的话，File2Txt 什么都收；也可以直接去 Excel 转 Markdown 处理电子表格、 PowerPoint 转 Markdown 处理演示文稿，或者 EPUB 转 Markdown 处理电子书。
手上是代码或网页？用 GitHub 转文本工具转仓库、转 GitLab 项目，或者转 本机文件夹。抓网页的话， Web2Txt 直接把网址抓成 Markdown。 想看这套论证的通用版本，还有一篇更长的 为 LLM 准备文档的指南。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。