PDF to Markdown for RAG: Tables and Images

When building a RAG system or enterprise knowledge base, PDFs are often among the first files to process: contracts, manuals, white papers, and internal policies all tend to live there. Extracting plain text may seem fast, but retrieval quality often suffers after chunking—heading boundaries disappear, tables become a stream of words, and images lose their connection to the surrounding text.

That is why many teams search for “PDF to Markdown” with a specific goal: output that can move into a chunking, embedding, and question-answering workflow, rather than another block of unstructured text.

Why isn’t plain text enough for RAG?

RAG quality depends heavily on whether chunks retain meaningful semantic boundaries.

• Without heading levels, a model has difficulty determining which section a passage belongs to.
• When tables are flattened, the relationship between rows and columns breaks down, making data-based questions more error-prone.
• If images are extracted only as separate files, references such as “see Figure 3” lose their anchor in the text.
• Repeated headers, footers, and page numbers can pollute summaries, search results, and model responses.

Markdown is commonly used as an intermediate format not because it looks polished, but because its lightweight syntax can represent headings, lists, tables, and image references for easier chunking and ingestion.

What should a PDF → Markdown conversion preserve for RAG?

Markdown intended for a knowledge base typically needs these structural signals:

1. Heading hierarchy
   Hierarchical markers such as # / ## define section boundaries and inform many chunking strategies.
2. Lists
   If steps, clauses, or bullet points degrade into ordinary paragraphs, retrieval loses the signal that they are a set of related items.
3. Tables
   Standard Markdown tables preserve row and column relationships, making it easier to reference data in later Q&A.
4. Image references
   Images should remain as relative-path references at their original locations in the text and be packaged with the image files, rather than becoming empty links.
5. Clean body text
   Repeated cross-page headers, footers, and page numbers should generally stay out of the corpus. At the same time, source page markers can be useful when you need to trace content back to the original PDF.

SimplifyAI’s PDF-to-Markdown workflow is designed for this type of structured extraction. It aims to retain headings, lists, tables, image assets, and header/footer cleanup where possible. Line breaks in English and Chinese text are also merged according to reading conventions, reducing noise from words split across lines.

Source page markers and headers/footers: traceability or cleaner content?

Knowledge-base teams often need to balance two goals:

• You need to trace content back to the original page: Keep source page markers so a matching chunk can be linked back to the corresponding PDF page.
• You need cleaner training or retrieval content: Remove page-number annotations and continue cleaning repeated headers and footers across pages.

In SimplifyAI’s PDF “Extract Markdown” settings, you can choose these options separately:

• Keep source page markers (enabled by default): Retains source PDF page-number annotations in the Markdown for easier traceability.
• Keep headers and footers (disabled by default): Repeated content across pages is removed where possible by default; enable this only when you need to compare against the original file.

These settings do not change the structured extraction itself, but they directly affect corpus cleanliness and source traceability. A practical approach is to process a sample with the default settings first, then adjust based on your knowledge-base standards.

A practical workflow: from PDF to ingestion-ready Markdown

1. Upload the PDF and select “Extract Markdown.”
2. Choose source page marker and header/footer options based on your knowledge-base requirements.
3. Review the heading hierarchy, tables, and image references in the preview.
4. Download .md, or download a ZIP containing images/, then send the output into your chunking and embedding workflow.

The deliverable is intended to preserve semantic structure, not visual layout. In other words, the goal is to help a model understand sections, lists, and tables—not to recreate a PDF’s two-column page design.

Current limitations: set expectations early

Well suited for:

• Single-column PDFs with a clear text layer
• Documents where headings, lists, and tables need to enter a RAG system or knowledge base
• Workflows that need images packaged alongside their positions in the text

Requires human review:

• Reading order in multi-column layouts
• Semantic reconstruction of complex equations
• Scanned files (the current version does not position OCR output as a default capability)
• Highly irregular tables positioned manually by coordinates

If you ultimately need to turn structured content back into editable Word, see Why does PDF to Word formatting change?. If the source file is already Word, see How to preserve table structure and heading hierarchy when converting DOCX to Markdown.

Next step

Choose a real PDF that will enter your knowledge base and convert it to Markdown with SimplifyAI. Check three things: whether headings support chunking, whether tables remain readable by rows and columns, and whether images stay in the correct places in the text. Confirming these points is closer to the real goal of RAG than asking whether the output looks identical to the PDF.

Related reading

• Why does PDF to Word formatting change? Fonts, lists, and page breaks explained
• How to preserve table structure and heading hierarchy when converting DOCX to Markdown
• How to convert Markdown to editable Word: A practical DOCX workflow for technical documentation