跳到正文

PDF → Markdown

把 PDF 转成可编辑、搜索、检索的 Markdown。

结构化 Markdown:标题、表格、列表和阅读顺序保留,供 RAG、Obsidian、Notion 和文档站使用。

100% 在浏览器本地处理。文件不会离开你的设备。最大 50 MB。

在浏览器里转换

放下 PDF,得到有结构的 Markdown。

不上传。标题、表格、列表和大纲得以保留 — 然后复制或下载。

100% 隐私安全 · 文件不会离开你的浏览器

将 PDF 拖放到此处,或

点击浏览文件
完整文档 100% 本地处理 最大 50MB
没有 PDF?

问题

PDF 记住的是页面长什么样,而不是内容是什么意思。

PDF(Portable Document Format)用来保存和交换电子文档,让它在每台设备、每个软件里看起来都一样。做合同、报告、打印手册时,这是优点。但当你需要的是内容时,这就是问题。

PDF 保存的是「这份文档应该长什么样」,而不是「这份文档的内容是什么结构」。
PDF 擅长什么

为呈现而设计

特点实际意味着什么
固定排版字体、图片、表格、间距、页眉页脚通常不会因设备不同而明显变化。
跨平台Windows、macOS、Linux、iOS、Android 都可以打开。
适合打印页面尺寸和打印排版能很好保留,因此广泛用于合同、报告、论文、手册。
这种设计在哪里失效

不利于工作,更不利于 AI

特点为何拖累现代工作流
结构不够友好PDF 更关心页面长什么样,而不是内容是什么结构。机器很难还原标题、段落、列表和表格。
编辑不方便相比 Word、Markdown,PDF 并不是为频繁编辑和重新组织内容设计的。
解析困难字体嵌入、多栏排版、表格、图片、脚注都会增加内容解析难度。

把 PDF 直接丢进知识库,往往不是最好的第一步。模型可能拿到文字,但拿不到结构。

目的地

Markdown 保住内容,并把结构写清楚。

Markdown 是一种轻量级标记语言。用简单的文本符号表示标题、段落、列表、表格、链接、代码。即使不渲染,源文件本身也比较容易阅读。

# Product Documentation

## Introduction

Markdown is simple and easy to read.

- Easy to edit
- Easy to search
- Easy to convert

Markdown 有什么不同

结构清晰

#、##、- 等符号明确表示标题和列表。

纯文本

本质上是文本文件,不依赖复杂排版格式。

易于编辑

用任何文本编辑器就能改,不需要专业办公软件。

易于阅读

原始 Markdown 本身也有较好的可读性。

体积小

相比 PDF、Word,通常更加轻量。

易于搜索

结构化文本可以方便地进行全文搜索。

你得到的不只是文字,还有一棵树。

这种层级,正是现代内容工作流所依赖的。

Product Documentation
└── Installation
    └── Requirements
        ├── Node 18+
        └── A valid API key

如果下一步是编辑、检索或生成,Markdown 已经是那个工作该有的格式。

两种格式,两份工作

PDF 负责交付。Markdown 负责工作。

PDF 保存文档长什么样,Markdown 保存文档是什么。
PDFMarkdown
核心目的保持页面和视觉排版表达内容和结构
可编辑性★★★★★★★
机器解析★★★★★★★
内容搜索★★★★★★★★
AI 处理★★★★★★★
RAG不太适合直接处理非常适合
版本控制不方便非常方便

这两种格式不是敌人,只是分工不同。缺的是中间这一步转换。

产品

PDF to Markdown 是缺失的那一步,不是新奇转换器。

大量重要资料已经是 PDF。你接下来要做的工作却不是:改写、搜索、检索、总结、发布。这些工作需要结构。

PDF — 固定排版,机器难以理解PDF to MarkdownMarkdown — 可编辑、可搜索、AI 友好LLM / RAG / 知识库 / 工作流

你买到的不是「从 PDF 里抠出来的字」,而是后续系统真正能用的文档。

转换应当还原什么

正文按阅读顺序的文字
标题与大纲章、节、小节
表格行列结构,而不是表格的图片
列表条目,而不是画布上剩下的项目符号
链接仍然可以跟随的目标地址
文档结构关系,而不只是字符

把 PDF 转成干净、有结构的 Markdown —— 可用于编辑、搜索、AI、RAG 等场景。

转换

选对格式

一条内容链路,三份工作。

把它们当成链条,而不是三选一:PDF 用于交付和阅读 → Markdown 用于编辑和处理 → PDF to Markdown 把已有 PDF 变成真正能用的结构化内容。

PDF = Presentation / Distribution / Archive

当内容已经定稿

PDF 最适合内容已经确定,需要稳定展示、分享、打印或归档。

PDF 的工作,一句话:别人看到的,要和我做出来的尽可能一样。

场景为什么用 PDF
合同格式固定,方便双方确认和归档。
报告图表、文字、页面布局保持一致。
论文 / 研究适合正式发布和阅读。
电子书章节、图片、页面排版得以保持。
产品手册下载后可以直接阅读或打印。

如何工作

三步把 PDF 转成 Markdown。

01

上传

报告、手册、论文、员工手册、SOP 或归档 PDF —— 也包括文字、表格、图片、链接混在一起的文件。

02

转换

我们还原的不只是一堆字:还有标题、列表、表格、链接和阅读顺序,让 Markdown 仍然像一份文档。

03

使用

编辑、搜索、切分、Embedding、发布、交给 LLM、放进 Git。

PDF转换结构化 Markdown你的工作流转换

使用场景

PDF to Markdown 用于 RAG、文档和内容复用。

最核心的场景

AI / RAG 知识库

公司往往已经有上千份 PDF:产品手册、技术文档、内部 SOP、合同、研究报告、培训资料。目标是做一个能根据这些资料回答问题的助手。把 PDF 直接扔进流水线,通常不是最佳方案。

你已经有的那一堆

  • 产品手册
  • 技术文档
  • 内部 SOP
  • 合同
  • 研究报告
  • 培训资料

真正能跑通的流水线

PDF
  → structured Markdown
  → chunking
  → embedding
  → vector database
  → RAG
  → AI assistant

PDF to Markdown 是 AI 知识库的数据准备阶段。没有结构,切分会切错位置,Embedding 会混进无关段落,检索返回的是一团文字而不是答案。有了 Markdown,标题就是标题,表格就是表格,一个章节可以按章节被检索到。

适用于 ChatGPT 与 RAG 的 PDF 转 Markdown

转换前后

提取文字,并不等于理解文档。

之前 — 程序眼里的 PDF 常常是这样
Introduction
Getting started

Install the CLI...

1. Download
2. Configure
之后 — 同样的内容变成 Markdown
# Introduction

## Getting started

Install the CLI...

1. Download
2. Configure

页面上的一行行字。顺序也许对,也许不对。标题层级只能猜。转换之后,标题、边界和层级都明确了 —— 这就是从页面上抠字符串,和还原一份文档的差别。

转换之后

一次转换,三个去向。

把 PDF 留给人看。当下一个读者是编辑、搜索索引、模型或网站时,再转换。

PDF阅读 / 分享 / 打印 / 归档
阅读 / 分发人在读这一页
转换提取内容
Markdown结构化的内容源
人工编辑内容运营
AI / RAG知识库
网站HTML / 文档站

PDF

阅读 / 分享 / 打印

Markdown

写作 / 结构 / 处理

PDF to Markdown

提取 / 转换 / 再利用

给谁用

写给继承了一堆 PDF、却还要把事情做下去的人。

AI 与平台团队

把手册、SOP、合同、培训材料做成带 RAG 的助手。

研究人员与分析师

在论文和长报告之间搜索、比较、提问。

文档与内容团队

把 API PDF、用户手册、员工手册迁进 Git、Notion 或文档站。

任何被 PDF 卡住的人

编辑、抽表格、做成网站,或复用一份从来不是工作文件的 PDF。

如果 PDF 已经完成使命,就让它继续做 PDF。如果工作还没做完,就转换它。

人们会搜什么

扫描件、表格、RAG、对话框,还有整夹文件。

这些查询就挨在主词旁边。每一项都是文件必须扛住的工作,不是再讲一遍格式。

OCR用 OCR 把扫描 PDF 转成 Markdown

扫描件没有文字层,必须先 OCR;只有 OCR 仍是一串字。有用的路径是 OCR 加结构:阅读顺序、标题层级,表格写成表格而不是格子照片。这样扫描件才能被搜索、切分或编辑。合同、发票常是扫描件;数字原件可跳过 OCR,扫描件不能跳过大纲。对比度差、歪斜、手写混排仍会失败。把 OCR 原文直接进知识库,索引的是噪声。

打开 OCR 转换器
RAG给 RAG 和 Embedding 用的结构化文件

把 PDF 原样做 Embedding,切分器常切在表格或章节中间,因为它没看到标题。检索回来的是看起来相关的一团字。先给流水线带明确标题和真表格的 Markdown,切分才能按大纲走:一节、一张表、一个列表。Embedding 更接近单一主题。chunk 大小仍要你选。转换避免模型把页眉、页脚和页码当成答案。

面向 LLM 与 RAG 的 Markdown
结构保住表格和标题

复制粘贴和粗暴提取会把双栏报告拍扁:标题只是字号大,表格变成空格。下游不能按列排序,也不能检索「4.2 节」。转换应输出 Markdown 标题和管道表格,阅读顺序跟人读的一致,多栏也尽量保住。表格若是截图,必须对图做 OCR。检验很简单:能否跳大纲,能否复制一行。

提取表格为 Markdown
ChatGPT转换,还是复制粘贴进 ChatGPT

粘进 ChatGPT、Claude 或 Gemini 适合偶发总结,不适合当资料库。模型拿到顺序不稳的文本块,标题和表格只能猜。无法给源文件做版本、重新切分,或把干净文件交给同事。先转换再提问:大纲在文件里,同一份可给别的模型、内部 RAG 或 Git。聊天窗口用来问问题,不要当唯一提取器。

为 ChatGPT 与 LLM 转换
批量批量把 PDF 转成 Markdown

一份文件是演示。真正的工作是整夹手册、合同归档、论文库。批量应保留文件名,跳过已有 .md 的,并在扫描件需要 OCR 或表格塌掉时明确失败。输出放原件旁或平行目录,方便 diff 和重跑。之后可建索引、做 Embedding 或发布。先拿难看样本试跑,再对全集开任务。

打开批量转换器

常见问题

转换之前,值得先回答这些问题。

为什么不直接把 PDF 上传给 ChatGPT、Claude 或 Gemini?

单次问答可以。但一份 100 页报告往往仍是结构很弱的文本块:标题、表格、章节边界不可靠。转成 Markdown 后,大纲是明确的——Executive Summary、Market Size、Competitive Landscape——总结、抽取和问答才有抓手。做知识库时差距更大:RAG 需要带真实标题的切片,而不是页面坐标。转换仍完全在浏览器内进行,文件不会上传到我们这边。

为什么是 Markdown,而不是 Word 或纯文本?

Word 仍把排版混进文件里。纯文本丢掉了层级。Markdown 保留内容和结构,去掉页面设计——这正是编辑、Git、搜索、Embedding 和 LLM 需要的。

你们实际提取什么?

文字、标题、表格、列表、链接和文档结构。重点不是生硬倒出一堆字,而是得到一份仍有大纲的文件。页眉、页脚和页码会自动去掉。

扫描件怎么办?

很多 PDF 其实是页面的图片。那些需要先 OCR,才谈得上结构。请使用内置 OCR 转换器,它会在浏览器里识别文字。扫描件,正是「直接解析 PDF」在现实中失败的原因之一。

多栏排版、脚注、嵌入字体、混排表格能保住吗?

这些是难点——而且很常见。这也是为什么需要专门的 PDF → Markdown 步骤。只把字符串拼在一起的转换,会打乱阅读顺序,也抓不到大纲。

这是给单文件用,还是给整个归档用?

两者都是。一份报告,方便你拿去问大模型。一千份手册、SOP、培训 PDF,方便切分、Embedding 和检索。整夹文件请用批量转换器。产品都是这个准备步骤——并且始终在本地完成。

原来的 PDF 还要留着吗?

要,当你需要一份稳定、保真打印、可分享的原件时。转换并不取代合同、发票或归档副本。它给同一份内容第二次生命。

Markdown 还能再变成网站或其他格式吗?

这正是转换的原因之一。Markdown 很容易变成 HTML、PDF、Word、文档站、FAQ、博客和 AI 数据集。PDF 是下载文件,Markdown 是源文件。

开始使用

别再把 PDF 当成终点。

PDF 适合阅读和分享,但并不是为现代内容工作流设计的。Markdown 让内容结构化、可编辑、可搜索,并且对 AI 友好。

把 PDF 转成干净、有结构的 Markdown —— 可用于编辑、搜索、AI、RAG 等场景。