ChatGPT missed PDF table rows? Check pages, row counts, and fields
Before asking ChatGPT to total a PDF table or list every item that meets a condition, build a checklist from the source pages: which pages are in scope, which data rows you expect, and which fields each row must retain. Then compare the output against that checklist, row by row. A fluent answer or a matching row count is not enough to establish that nothing was omitted.
This check only supports the scope you actually reviewed. If you still cannot establish how many rows the source contains, or which pages belong to the same table, keep that gap explicit. Do not treat the model's count as the full set of expected rows.
Check what the PDF processing path can read
As of October 10, 2026, OpenAI's file upload documentation says that support for embedded images depends on the plan and file type. ChatGPT Enterprise supports visual retrieval for PDFs; other plans and document types use text-based retrieval, extracting digital text rather than embedded images.
The official PDF visual retrieval FAQ also distinguishes upload locations. Within its Enterprise scope, PDFs added to GPT Knowledge or Project Files use text-only retrieval. PDFs attached during an interaction with a published GPT or within a Project conversation use visual retrieval. These documents do not promise complete extraction of every table row.
If a condition depends entirely on a scanned image, cell shading, or page layout, a successful upload does not establish that the relevant information was read. Inspect the field on the source page, then check which processing path applies to your plan and upload location. Even when images can be read, the row-by-row checks below still matter.
Build a checklist you can compare with the source
Start by transcribing all data rows in the specified table, then apply the filter. If the first request only asks for matching items, an absent row becomes difficult to investigate: did it fail the condition, or was it never read?
Build the expected-row checklist by inspecting the source pages yourself, or use the original spreadsheet after confirming that its version and scope match. Do not take both the expected and actual row counts from the same model response and treat their agreement as independent verification.
| Check | Record from the source first | Inspect in the output |
|---|---|---|
| Pages and table boundaries | PDF viewer page positions, printed page labels, table name, and start/end boundaries; record both page-number systems if they differ | Coverage of the specified scope, skipped pages, or rows brought in from another table |
| Expected fields | Column names, units, filter fields, and the mapping of multi-level headers | Missing or shifted fields; units or notes mistakenly included in values |
| Data rows | Data-row counts and original IDs for each page, excluding headers, subtotals, and footers | Missing, extra, and repeated IDs, as well as the row count |
| Continuation across pages | Whether the last row continues on the next page, and whether the next page starts with a repeated header | A single record split into two, or continuation text dropped |
| Merged cells and empty values | Which rows a merged cell covers; distinguish blanks, zeros, dashes, and unreadable text | Values filled down without justification, blanks changed to zero, or illegible content guessed |
| Source location | A page position, table name, and original ID for each row; add a manual row position within the table when no ID exists | Whether each location actually leads back to the corresponding source row |
If the source has no IDs, keep any manually added locator separate from the original fields. Sequential numbers assigned to the output do not prove that every source row is present. Check whether original IDs are unique, too. If one ID legitimately appears in several records, compare those records using their page and row positions rather than deleting repeated IDs.
Teaching example: matching counts can still hide a missing row
The following data was manually designed for teaching. Every ID, value, and illustrative page location belongs only to this example. No PDF was created or uploaded, and the example was not run in ChatGPT. The lists below are an expected answer and deliberately constructed errors.
Imagine a promotional-materials list split across two illustrative pages, with three data rows on each. Both pages have headers, and the second has a footer reading "Number of records: 6." Neither headers nor that footer count as data rows. The task is to find rows whose Action field is exactly "Reprint" and total their quantities.
| Teaching row ID | Item | Action | Quantity (units) | Manually assigned source location |
|---|---|---|---|---|
| M01 | Folded leaflet | Reprint | 40 | Illustrative page 1, data row 1 |
| M02 | Poster | Keep | 10 | Illustrative page 1, data row 2 |
| M03 | Guide card | To confirm | Blank | Illustrative page 1, data row 3 |
| M04 | Sticker | Reprint | 25 | Illustrative page 2, data row 1 |
| M05 | Information card | Reprint | 15 | Illustrative page 2, data row 2 |
| M06 | Name badge | Keep | 0 | Illustrative page 2, data row 3 |
The expected answer has three stages:
- There are six data rows: M01, M02, M03, M04, M05, and M06, each appearing once. Preserve M03's blank and M06's zero.
- Check each Action and Quantity field against the source before filtering. The matching IDs are M01, M04, and M05: three rows.
- Their quantities are 40, 25, and 15, totaling 80 units. M03 does not meet this filter condition. Its blank must stay blank, but it does not prevent totaling the three matching rows.
Now consider a deliberately incorrect list: M01, M02, M03, M04, M04, M06. It still has six rows, but M05 is missing and M04 appears twice. A count-only check misses the problem. Comparing IDs identifies the missing row.
Even if all six IDs are present, reading M05's Action as "Keep" instead of "Reprint" would still produce the wrong filtered result. Matching row identities supports a row-coverage check; field values need their own verification.
A copyable prompt for row-by-row transcription
Use this prompt to request output that is easier to check manually. Fill in the brackets from the source pages, using "unknown" where necessary. The prompt does not guarantee complete extraction.
First transcribe every data row in the specified table. Do not filter, total, or summarize yet.
Scope: PDF viewer page positions [first through last]; printed page labels [if any]; table name [name].
Required fields: [original ID, column names, and units]. My manually verified expected-row checklist and/or per-page row counts are [insert them, or write unknown]. Headers, subtotals, and footers are not data rows.
Attach a verifiable source location to each row, including the PDF viewer page position, table name, and original ID. If the source has no ID, explicitly label any added locator. If a page number or location cannot be verified, write "cannot confirm" rather than inventing one.
Preserve source values. Distinguish blanks, zeros, dashes, and unreadable content. Do not fill in values, change units, or treat a row's continuation on the next page as a new data row. Retain uncertain fragments and explain what is unclear.
After the table, list the number of rows actually output for each page, repeated IDs, and any unreadable or uncertain content you noticed. If I supplied a manually verified checklist, also identify IDs missing from or additional to that checklist. If the checklist is unknown, do not claim that completeness has been verified.
Wait until I have checked the output against the source pages before filtering and calculating using [specific field and condition].
When the response arrives, work through your checklist page by page and row by row, then verify the filter and numeric fields. A statement that everything has been read, or an empty list of issues, cannot replace that comparison.
Narrow the problem when gaps remain
If you cannot establish a clear row mapping for one page, focus on that page and any adjacent continuation pages. Retain the source locations for each batch, then check for duplicates and omissions across batches. If you have the original table used to produce the PDF, you can also use it to build the checklist after confirming that the version and scope match. These are ways to make discrepancies easier to locate; this article did not test their comparative effectiveness.
When only part of the content can be confirmed, report which pages and rows were checked and which pages or fields remain uncertain. Do not label a partial total as the whole-table total. If the full set of source rows is unknown, the completeness rate must remain unknown too. Switching models or asking again does not close that gap without additional evidence from the source pages.
A January 2025 OpenAI community discussion provides a historical example of this reader need: one user reported that a filtered list from a multi-page PDF table omitted items. That individual report cannot establish today's failure rate, and replies from that time are not current product specifications. The method here gives you a way to trace the output back to source rows and state what has been confirmed before you calculate.