markitdown vs pdf-inspector - PDF 转 Markdown 工具深度对比
markitdown 和 pdf-inspector 是当前最常被放在一起比较的两个开源「PDF 转 Markdown」工具——前者来自微软，后者来自 Firecrawl，都是免费的，都号称给 LLM 喂干净文本。但当你真的拿一批真实 PDF 跑一遍，差距是数量级的。
本文基于官方 opendataloader-bench 基准（200 份真实 PDF、五引擎横向对比、OCR 全关）做客观拆解，不吹不黑，先摆数据再给结论。
一图看懂：关键指标对比
| 指标 | pdf-inspector | markitdown | 说明 |
|---|---|---|---|
| 所属 | Firecrawl（开源 Rust 库） | 微软（开源 Python 库） | 生态背景不同 |
| 核心定位 | 先分类后提取的解析引擎 | 万能格式转换工具 | 一个专精 PDF，一个广而不深 |
| 类型判定 | 10–50ms 判定 + 置信度 + 逐页信号 | 无 | 决定 OCR 成本的关键能力 |
| 综合评分（0–1） | 0.875 | 0.589 | 五引擎中排第一 |
| 阅读顺序 | 0.915 | 0.844 | 多栏还原质量 |
| 表格 (TEDS) | 0.814 | 0.273 | 差距最大的一项 |
| 标题识别 | 0.788 | 0.000 | markitdown 几乎不还原标题层级 |
| 全量耗时（200 文档） | 0.470s | 16.165s | 快 34 倍+ |
| 语言绑定 | Rust/Node/Python/WASM/CLI | Python（有 CLI 和 .NET 端口） | pdf-inspector 五端 |
| 浏览器端运行 | WASM 单线程，无需跨域隔离 | 需 Python 运行时 | pdf-inspector 可纯前端 |
| OCR 策略 | 选择性 OCR（只送需要的页面） | 插件扩展 | 架构理念不同 |
数据来源：pdf-inspector 官方仓库 benchmark（opendataloader-bench 语料库 200 份真实 PDF，2026 年 7 月刷新）。
先说结论
- PDF 是主要输入、要喂给 LLM、在意表格和多栏质量 → 选 pdf-inspector。综合最准、表格断层领先、速度快 30 多倍，还能先判定类型再决定要不要花 OCR 的钱。
- 已经在 Python 项目里、输入五花八门（URL、PPTX、XLSX、音频都要碰）、想要插件生态 → markitdown 依然可用，但它处理 PDF 的质量（表格 0.273、标题 0.000）意味着你大概率还需要一个专职 PDF 解析器兜底。
定位差异：一个「万能转换器」，一个「PDF 解析引擎」
markitdown 是什么
微软开源（github.com/microsoft/markitdown），定位是"Python 库 + CLI"，把各种常见文档转成 Markdown 供 LLM 使用。它的优势：
- 生态成熟：2024 年开源后社区热度高，Python 开发者熟悉，文档和第三方集成多
- 格式面广：除 Office 三件套外还覆盖图片、音频转录、EPUB、ZIP 等
- 可扩展：插件体系支持接入 LLM 描述图片等自定义能力
它处理 PDF 的短板（基准实测）：
- 综合评分 0.589，五引擎垫底
- 标题识别 0.000：几乎完全不还原标题层级，转出的 Markdown 缺结构
- 表格 TEDS 0.273：表格基本靠猜
- 全量 16.165s，比 pdf-inspector 慢 34 倍
- 强依赖 Python 运行时，浏览器端跑不了
pdf-inspector 是什么
Firecrawl 开源（github.com/firecrawl/pdf-inspector），定位是"Rust 解析引擎 + 五端绑定"，也是 Firecrawl 混合 OCR 管线的底层引擎。它的优势：
- 先分类后提取：10–50ms 判定 TextBased / Scanned / ImageBased / Mixed，给出置信度和需要 OCR 的页码，成本可控
- 质量第一：综合 0.875、阅读顺序 0.915、表格 TEDS 0.814，全部居首
- 毫秒级：文本型 PDF 本地 200ms 内全流程完成；200 份文档总耗时 0.470s
- 版面感知：多栏、报纸式布局重建阅读顺序，CID/Type0 字体经 ToUnicode CMap 正确解码（中日韩友好）
- 部署灵活：npm / PyPI / crates.io / 浏览器 WASM 四种安装形态，WASM 版文件不出设备
它的边界：
- 只管 PDF——Word、Excel 等其他格式不在射程内
- 默认构建不含 OCR，扫描件要么接原生选择性 OCR，要么自己路由到外部服务
场景化选型建议
| 你的场景 | 推荐 | 原因 |
|---|---|---|
| 批量 PDF 入库 RAG / 微调语料 | pdf-inspector | 速度 + 表格 + 结构全面占优，语料质量直接受益 |
| 多格式混杂（Office/网页/音视频都有） | markitdown + 兜底 | markitdown 当胶水，PDF 重活交给专职引擎 |
| 服务端高并发解析 | pdf-inspector | 异步 API 走 libuv 线程池不阻塞事件循环 |
| 纯前端、文件不出设备 | pdf-inspector | WASM 版单线程构建无需 COOP/COEP 头 |
| 要控制 OCR 成本 | pdf-inspector | 逐页路由信号 + 选择性 OCR，54% 的 PDF 免 OCR |
数据透明
以上对比数据全部来自 pdf-inspector 官方仓库公布的基准（OCR 关闭、本地引擎对比），方法论与原始产物公开可查。基准有代表性但不等于全宇宙，建议拿自己的真实文档实测后再做最终决定。