PDF text extraction vs. OCR vs. layout-aware Markdown

Plain text extraction reads the text layer already inside a PDF and returns it immediately, using pypdf. It is fast and works the moment a file is uploaded, but it returns a stream of characters: headings are not marked, a table becomes a run of numbers, and there are no page numbers to cite.

It is the right choice when the only goal is to search a document for a keyword or paste a short passage somewhere, and structure does not matter.

A layout-aware conversion, built with Docling, follows shortly after and reconstructs the document's structure: a page anchor before every page, headings that form an outline, and tables detected well enough to export as CSV or XLSX. This is the version worth citing from.

Because it runs as a background step rather than blocking the initial upload, a workflow can show the immediate plain text first and swap in the structured version once it finishes.

Neither of the above helps a scanned page or a photograph, because there is no text layer to read. OCR recognizes the characters on the page image itself, at 3 units per page on Pro and API. It is a separate, paid step, not something plain extraction or Markdown conversion does on its own.

A mixed document, part digital text and part scanned pages, only pays the OCR rate for the pages that actually need it, since pages with an existing text layer skip that step entirely.

The choice follows from the source, not preference. Most documents only need one of the three; the combination matters mainly for a mixed or uncertain source.