Extract Text from PDFs Programmatically

Reading order and layout recovery decide whether text pulled from a PDF is usable. A PDF has no concept of a paragraph, sentence, or table, so every extractor infers structure from where text sits on the page. To extract text programmatically, initialize PDFNet with your license key, open the file with the Apryse Server SDK, and read each page with TextExtractor. That step belongs to the base Server SDK, runs on Windows, Linux, and macOS, and returns Unicode text with word and line positions. When your code needs headers, footers, lists, and tables identified as separate blocks, add Smart Data Extraction. It returns JSON with page numbers and bounding rectangles, needs a separate add-on license, and runs on Windows and Linux (x64 only). A scanned PDF has no text layer, so the OCR Module, also a separate add-on, creates one first. All of it runs inside your own infrastructure.

A PDF stores positioned text runs, not paragraphs. The ISO PDF standard does not define reading order, and a typical PDF has no concept of a sentence, paragraph, or table. The run order follows the program that wrote the file, not the order a person reads.

Three layouts expose the gap: multi-column pages, running headers and footers, and tables set inside running text. Reading order also changes with document type. A magazine page, a newspaper article, and an academic paper each ask for a different order.

Each failure carries into whatever consumes the text. A language model that ingests interleaved columns reads sentences the author never wrote. A search index that stores footers inside paragraphs returns the wrong passages. A review screen that highlights the wrong region teaches your users to distrust it.

Three separate jobs sit under the phrase text extraction. Reading the text layer, with words, lines, paragraphs, and positions, is a base Server SDK operation. Recovering structure, meaning which blocks are headers, footers, lists, and tables, is the job of Smart Data Extraction, an add-on that handles document structure recovery. Generating a text layer where none exists is OCR, a separate add-on. Scope them separately.

The structure foundation is deterministic: the same PDF produces the same recovered structure on every run. Purpose-built AI handles the fields that need interpretation, such as key-value pairs and page classification.

Tables inside running text are a parsing problem with their own method. This page stops at that boundary, and document parsing covers tables.

This section covers Apryse Server SDK integration using C#, Java, and Python 3 on Windows and Linux. For other languages or platforms, see the Server SDK get-started guide.

TextExtractor is part of the base Server SDK. It needs no add-on module and no add-on license. It normalizes text to Unicode, assembles words, lines, and paragraphs, removes duplicated strings, and reconstructs reading order. The text extraction guide states the limit: the reconstructed order is not guaranteed to match the order a person reading the page would follow.

You need a trial key from dev.apryse.com and a call to PDFNet.initialize() before any extraction call. It sets up the library, registers your license key, and runs once per process. The call name changes by binding, as the table shows.

Keep the license key out of source control. The examples read it from the APRYSE_LICENSE_KEY environment variable.

Each program prints the same structure. The excerpt below is trimmed to page 1 of the sample contract. Every element carries a type and a rect of the form [left, top, right, bottom] in PDF points, and each page object carries its pageNumber. The root object also holds document properties: the coordinate system, the producer, and the schema version. The JSON specification defines every element type.

Your application uses the page number and rect to overlay or annotate the source page, to route a paragraph to a reviewer, or to cite the page a passage came from. The same JSON feeds semantic search and RAG preprocessing.

Confidence scores differ by mode. Form field identification, key-value extraction, CAD title block extraction, and document classification each return a confidence score. Table extraction does not, so treat table output as unscored.

Apryse supplies the extraction building blocks. Your application owns the pipeline around them, including queues, review, and storage.

Multi-column pages, sidebars, and running headers break order-based extraction first. The base TextExtractor reconstructs reading order from word and line positions, and the e_extract_using_zorder flag switches it to the order the content was drawn in. Both return text. Neither labels a block.

Smart Data Extraction recognizes the page the way a person sees it. Its Document Structure Recognition engine separates paragraphs and lists, headers and footers, section columns from table columns, and tables embedded inside paragraphs. It reads visual positioning, spacing, indentation, and structural boundaries to do so. Your code receives blocks instead of rebuilding them from coordinates.

SDK 12.0 added Markdown output to the Document Structure API. It carries paragraphs in reading order, heading levels 1 through 6, nested lists, and tables into the format RAG and LLM pipelines ingest. The output is data for a pipeline, not a visual reproduction of the page. It runs on Windows and Linux in every supported SDK language and is included in an existing Smart Data Extraction license.

What this does not cover: Smart Data Extraction does not convert PDFs to Word, Excel, or PowerPoint. The Structured Output Module does that.

A scanned PDF stores each page as an image. TextExtractor analyzes textual content only, so rasterized text in a scan, and vectorized text where glyphs are converted to outlines, returns nothing. If a page shows words on screen and extraction returns an empty string, the page is an image.

OCR generates the missing text layer. The OCR Module is a separate add-on module with its own license. Run it first, then extract. OCR text is stored as invisible text, and TextExtractor extracts invisible text by default. The OCR capability page covers engines and setup, so this page does not repeat them.

For the full pipeline from scan to usable text:

A PDF font maps glyph codes to characters. When the mapping is complete, extraction returns the characters you see. When it is missing or wrong, any extractor that reads the text layer hits the same limit: the glyph is on the page, and the character is not recoverable from the file.

TextExtractor normalizes all text to Unicode and expands ligatures by default. The default mapping covers fi, ff, fl, ffi, ffl, ch, cl, ct, ll, ss, fs, st, oe, and OE, so a fi glyph extracts as two letters and search matching stays consistent. Pass the e_no_ligature_exp flag to keep ligature characters as they are.

Hidden and duplicated text get the same treatment. The extractor removes duplicated strings that generators use to fake bold or drop shadows, and it extracts invisible text. Flags change each default: