跳到正文
转换 PDF

PDF → Markdown

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

PDF 适合阅读和分享，却不适合编辑、搜索或 RAG。我们把 PDF 转成 Markdown，保住标题、表格、列表和大纲，便于文档、检索和 AI 使用。

将 PDF 转为 Markdown查看转换示例

提取的不只是文字，还有文档本身：标题、表格、列表、链接和层级——不是一堆没有结构的字符。

100% 在浏览器本地完成 — 文件不会离开你的设备。最大 50 MB。可在转换器中试用示例 PDF。

RAGLLMs知识库文档搜索网站

在浏览器里转换

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

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

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

将 PDF 拖放到此处，或

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

问题

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

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

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

为呈现而设计

特点实际意味着什么
固定排版字体、图片、表格、间距、页眉页脚通常不会因设备不同而明显变化。
跨平台Windows、macOS、Linux、iOS、Android 都可以打开。
适合打印页面尺寸和打印排版能很好保留，因此广泛用于合同、报告、论文、手册。
适合分发生成后可以比较稳定地作为最终版本阅读、分享和归档。
内容类型复杂一个 PDF 不只是文字，还可能包含图片、表格、链接、矢量图形、字体、扫描页面。
这种设计在哪里失效

不利于工作，更不利于 AI

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

你看到的

在页面上，一份 PDF 看起来可能是章节、小节、列表、表格。

Chapter 1
Introduction

This is the introduction...

1. Background
2. Methodology
3. Results

[Table]

程序看到的

程序往往看到的是另一回事：散落在画布上的文字、坐标、字体和图片。要还原真正的标题、段落边界、列表和表格，并不总是容易。

  • PDF 面向人阅读，强调视觉排版。
  • Markdown 面向结构化内容、编辑、程序处理和 AI。
  • 有了 Markdown，同一份文档就更适合搜索、知识库、RAG、Embedding 和 LLM。

把 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，通常更加轻量。

易于搜索

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

易于转换

可以转换成 HTML、PDF、Word 等格式。

适合程序处理

标题、段落、列表结构明确，方便程序解析。

适合版本管理

纯文本非常适合 Git 等版本控制系统。

跨平台

Windows、macOS、Linux 都可以处理。

AI 友好

结构化文本更容易被 LLM、Embedding、RAG 处理。

真正的原因

Markdown 把内容和视觉排版分开了。

PDF 问的是：这份文档在页面上应该长什么样？

Markdown 问的是：这份内容是什么，它的结构是什么？

这不是外观差异，而是工作方式的差异。

# Product Documentation

## Installation

### Requirements

- Node 18+
- A valid API key

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

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

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

AI 不只需要「文字」，还需要理解文字之间的结构和关系。对 AI / RAG 来说，标题层级、段落边界、列表、表格一下子变得明确。

因此 Markdown 非常适合：

LLMsRAG向量数据库EmbeddingsAI 知识库AI Agent语义搜索文档系统内容管理

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

两种格式，两份工作

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

PDF 保存文档长什么样，Markdown 保存文档是什么。
PDFMarkdown
核心目的保持页面和视觉排版表达内容和结构
可编辑性★★★★★★★
机器解析★★★★★★★
内容搜索★★★★★★★★
AI 处理★★★★★★★
RAG不太适合直接处理非常适合
版本控制不方便非常方便
文件大小通常较大通常很小
跨平台是是
人类阅读是是
页面布局强弱

你仍然需要 PDF。合同、报告、论文必须对每位读者看起来一样。当同一份材料要被复用、查询、更新或交给模型时，你需要 Markdown。

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

产品

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

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

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

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

转换应当还原什么

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

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

转换 PDF

选对格式

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

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

PDF = Presentation / Distribution / Archive

当内容已经定稿

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

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

场景为什么用 PDF
合同格式固定，方便双方确认和归档。
报告图表、文字、页面布局保持一致。
论文 / 研究适合正式发布和阅读。
电子书章节、图片、页面排版得以保持。
产品手册下载后可以直接阅读或打印。
发票 / 收据表单不会跑版。
公司文档适合正式文件分发。
课程资料课件、教材可以整理成一份 PDF。
打印页面几何结构能较好保证打印效果。
归档适合保存最终版本。

如何工作

三步把 PDF 转成 Markdown。

01

上传

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

02

转换

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

03

使用

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

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

使用场景

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

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

AI 用这种层级，搜索用它，编辑也用它。PDF 不会把它交给你。

转换之后

一次转换，三个去向。

把 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 等场景。

将 PDF 转为 Markdown查看转换示例