Multi-Page PDF Table Extraction Prompt Template

This prompt is designed for data engineers and platform developers who need to extract tables that span multiple pages of a PDF document into a single, unified JSON array. The primary job-to-be-done is converting unstructured, layout-dependent tabular data into a structured, machine-readable format suitable for database ingestion, analytics pipelines, or API responses. The ideal user is someone building an automated document processing system who understands that PDF tables are not just visual grids but complex structures with merged cells, repeated header rows, and page-break artifacts that must be resolved programmatically. You should use this prompt when you have a high volume of consistently formatted multi-page PDFs—such as financial reports, regulatory filings, or technical specification sheets—where manual extraction is not scalable.

This prompt is not appropriate for single-page tables, which can be handled with simpler extraction logic, nor for documents where the table structure is highly irregular or embedded within complex multi-column layouts that require visual segmentation before text extraction. It is also not a substitute for a dedicated PDF parsing library when the document contains selectable text layers; in those cases, use a library like pdfplumber or PyMuPDF to extract raw text and bounding boxes first, then use this prompt to resolve the logical table structure from that pre-extracted content. The prompt assumes you have already converted the PDF pages into a text representation that preserves positional information, such as a list of pages with word-level coordinates. If your PDFs are scanned images, you must apply OCR before using this prompt, and you should expect lower accuracy due to OCR errors in numeric cells and column headers.

Before implementing this prompt in a production pipeline, validate your extraction against a golden dataset of at least 20 multi-page tables with known ground truth. Pay special attention to failure modes: merged cells that span multiple rows or columns, page breaks that split a row across two pages, repeated header rows that should be deduplicated, and empty cells that should be represented as null rather than omitted. If your use case involves financial data, legal obligations, or clinical records, always include a human review step for any table where the row count after extraction does not match the expected count or where cell-level confidence scores fall below your defined threshold.

The following prompt template is designed to be wired directly into your extraction pipeline. It instructs the model to process a multi-page PDF, identify tables that break across page boundaries, and produce a single, clean JSON array of rows. The template uses square-bracket placeholders—such as [INPUT], [CONTEXT], and [OUTPUT_SCHEMA]—that you must replace with concrete values before sending the request to the model. This separation keeps the core logic stable while letting you swap in different documents, schemas, and constraints without rewriting the entire prompt.

textCopy
You are a precise data extraction engine. Your task is to extract all tables from a multi-page PDF document and return them as a unified JSON array.

## INPUT
[INPUT]

## CONTEXT
[CONTEXT]

## INSTRUCTIONS
1. Scan every page of the provided PDF for tabular data. A table is any grid of rows and columns, including those with merged cells or irregular borders.
2. When a table spans multiple pages, merge the fragments into a single logical table. Detect and discard repeated header rows that appear at the top of continuation pages.
3. For each logical table, produce a JSON object with the following structure:
   - `"table_id"`: A unique integer identifier for the table, starting at 1.
   - `"page_range"`: A string indicating the first and last page where the table appears, e.g., "3-5".
   - `"headers"`: An array of strings representing the column headers. Normalize whitespace and remove any newline characters within a single header.
   - `"rows"`: An array of arrays, where each inner array is a row of string values corresponding to the headers. If a cell is empty or missing, use an empty string `""`.
4. Handle merged cells by duplicating the value into each logical cell position it spans, based on the column headers.
5. If a table has no discernible headers, generate default headers as `"Column_1"`, `"Column_2"`, etc.

## OUTPUT_SCHEMA
Return ONLY a valid JSON object with a single key `"tables"` containing an array of table objects. Do not include any text outside the JSON.

```json
{
  "tables": [
    {
      "table_id": 1,
      "page_range": "[START_PAGE]-[END_PAGE]",
      "headers": ["[COLUMN_1]", "[COLUMN_2]"],
      "rows": [
        ["[ROW1_COL1]", "[ROW1_COL2]"],
        ["[ROW2_COL1]", "[ROW2_COL2]"]
      ]
    }
  ]
}

CONSTRAINTS

[CONSTRAINTS]

EXAMPLES

[EXAMPLES]

RISK_LEVEL

[RISK_LEVEL]

To adapt this template, start by replacing the [INPUT] placeholder with the actual PDF content, typically provided as base64-encoded text or a pre-extracted text representation. The [CONTEXT] placeholder should contain any document-level metadata, such as the expected number of tables or industry-specific terminology. The [CONSTRAINTS] block is where you enforce business rules, such as a maximum number of rows, a list of required columns, or a controlled vocabulary for certain cell values. Use the [EXAMPLES] block to provide one-shot or few-shot demonstrations of tricky cases, like a table with a multi-line header or a page break mid-row. Finally, set the [RISK_LEVEL] to guide the model's caution; for financial or clinical data, instruct the model to flag ambiguous cells with a "confidence": "low" note rather than guessing.

Before integrating this prompt into a production pipeline, validate the output against the expected schema. A post-processing script should check that the number of columns in every row matches the length of the headers array, that page_range values are within the document's actual page count, and that no table is missing. For high-stakes extraction, route any table where the row count changes after merging to a human review queue. This prompt is the starting point—combine it with a deterministic validator and a retry mechanism that feeds schema violations back into the [CONSTRAINTS] block for a second pass.

This prompt is designed to be one step in a larger document processing pipeline, not a standalone solution. Before the prompt is called, the application layer must handle PDF parsing, text extraction, and page segmentation. Use a library like pdfplumber or PyMuPDF to extract text with bounding box coordinates, then group text blocks by their vertical and horizontal alignment to identify table regions. The extracted text for each table region, along with its page number metadata, becomes the [PAGE_CONTENT] input. Do not send raw PDF bytes to the model; send pre-parsed, page-delimited text blocks. The application should also detect and flag pages that contain no tables to avoid unnecessary inference costs.

Post-processing is where the real engineering work lives. The model returns a JSON array of rows, but you must validate it before ingestion. Implement a schema validator that checks: (1) all rows have the same number of cells as the header, (2) no cell is null unless explicitly allowed by a [NULL_POLICY] flag, (3) merged cell indicators like [SPAN_CONTINUATION] are resolved into duplicated values or structured spans in your target schema, and (4) page break rows are removed or converted into metadata markers. If validation fails, do not retry the entire document. Instead, isolate the failing table region and retry extraction on that region alone with a more constrained prompt that includes the specific validation error message. Log every validation failure with the document ID, page range, and error type for later prompt improvement.

For high-stakes extraction where accuracy is critical, add a human review queue. Rows where the model's self-reported confidence is below a threshold, or where post-validation detects anomalies like unexpected column count changes, should be routed to a review interface. The interface should display the original PDF page snippet alongside the extracted row for side-by-side comparison. For model choice, prefer a model with strong vision capabilities if tables contain complex merged cells or non-text elements, but use a text-only model with pre-extracted text for cost efficiency on simple tables. Always version your prompt and track which prompt version produced which extraction batch so you can attribute errors and measure improvement over time.