← Back to Articles

Document Conversion and Text Extraction for RAG

See how PDFs, DOCX files, HTML, and Markdown are converted into normalized text for retrieval, chunking, embeddings, and reliable LLM context generation.

By Urban M.•
AIRAGOCRDocument ProcessingData Engineering
Document Conversion and Text Extraction for RAG

Document Conversion and Text Extraction for RAG

After a document is uploaded, the next job is to turn it into usable text.

This sounds straightforward until you work with real files. PDFs may have broken reading order. DOCX files may contain nested lists and tables. HTML may include navigation noise instead of content. Some scans have no embedded text at all, so OCR becomes necessary.

RAG quality is heavily influenced by this step because retrieval only works as well as the text you extracted.

The Goal of Conversion

The goal is not merely to “get text out.” The goal is to create a normalized representation that preserves enough structure to support chunking, retrieval, and citations later.

Useful outputs from conversion often include:

  • plain text
  • headings
  • page numbers
  • section boundaries
  • table content
  • links or source references
  • detected language

If you flatten everything into one long unstructured string, later stages lose valuable signals.

Why Different Formats Behave Differently

PDF

PDF is presentation-oriented, not content-oriented. Text extraction often struggles with:

  • multi-column layouts
  • headers and footers
  • repeated page furniture
  • broken reading order
  • scanned pages with no selectable text

DOCX

DOCX usually preserves structure better, but extraction still needs to handle:

  • headings
  • bullet lists
  • tables
  • comments or tracked changes

HTML

HTML can be excellent or terrible depending on the source. Clean article pages are easy. Complex enterprise portals often include menus, banners, footers, and scripts that need to be stripped.

Markdown

Markdown is usually the easiest format because headings and structure are explicit. It is often the cleanest ingestion source for technical knowledge bases.

Normalization Is the Real Output

Good extraction pipelines often transform format-specific outputs into a shared internal representation.

For example:

{
  "documentId": "doc_123",
  "title": "Incident Response Guide",
  "sections": [
    {
      "heading": "Escalation Policy",
      "page": 4,
      "text": "If a Sev-1 incident is confirmed..."
    }
  ],
  "language": "en"
}

This kind of structure makes chunking and retrieval far more reliable.

OCR Is a Separate Capability

Not every file contains machine-readable text. Some PDFs are scans. Some images are screenshots of reports. In those cases, optical character recognition is required before chunking can even begin.

OCR introduces new concerns:

  • recognition accuracy
  • layout detection
  • language support
  • cost and latency

You should treat OCR as a capability that can fail independently, not as a hidden detail inside generic parsing.

Preserve Structure Where Possible

The downstream system benefits if you preserve:

  • heading hierarchy
  • paragraph boundaries
  • list items
  • table rows
  • page references

Why? Because chunking often works better when it can use natural document boundaries instead of arbitrary character counts.

For example, the chunker may prefer to split at ## Access Policy rather than in the middle of a paragraph about access policy.

Common Cleanup Tasks

Most extraction pipelines need cleanup steps before the text is ready for chunking:

  • remove duplicated headers and footers
  • collapse excessive whitespace
  • fix broken line wraps
  • strip navigation or legal boilerplate
  • normalize character encoding
  • remove empty pages or sections

This is boring work, but it often has a larger effect on RAG quality than changing the embedding model.

What to Store After Extraction

The extracted result should usually be stored independently of the raw file. That gives you a reproducible intermediate artifact.

Useful fields include:

  • document ID
  • normalized text
  • structural sections
  • detected language
  • extraction method
  • extraction version
  • processing warnings

Versioning matters because extraction logic improves over time.

What the Frontend Should Show During Conversion

Most users do not need to see parser internals, but they do need clear processing feedback.

A simple UI for this stage should show:

  • that the upload is being processed
  • whether OCR was required or processing failed
  • whether the document is ready for search
  • a retry path for authorized users when extraction fails

This keeps document conversion observable without exposing unnecessary implementation detail.

Common Mistakes

Teams often lose quality here by:

  • treating PDFs like clean text sources
  • ignoring OCR edge cases
  • discarding headings and page metadata
  • chunking directly on raw parser output
  • failing to version extraction logic

If you do not know how the text was produced, you will struggle to explain retrieval problems later.

Recommended Baseline Approach

For a practical first version:

  1. use format-specific parsers
  2. normalize outputs into a shared internal schema
  3. preserve headings and source references where possible
  4. enable OCR only for formats or files that need it
  5. store extraction results with version metadata

This makes the rest of the pipeline easier to debug and evolve.

Final Takeaway

Text extraction is not just plumbing. It is the foundation for chunking, embeddings, retrieval quality, and source attribution.

If your extracted text is noisy or flattened, your RAG system will feel unreliable no matter how strong the model is.

The next article covers the next major design decision: how to split extracted text into chunks that retrieval can actually use.

Previous: Document Upload Architecture for a RAG System

Continue with: Chunking Strategies for Better RAG Retrieval

- asdf