PDF table to Markdown: check every row

A PDF table to Markdown conversion can look neat. A value may still sit in the wrong column. Borders and alignment are not enough. You need the right headers, complete rows, units and footnotes. This guide starts with a simple table, then tackles page breaks and merged headings. The worked numbers are a checking exercise. They are not a product benchmark. The goal is a clear table. Another person should be able to read it without the PDF beside them.

Define what a successful conversion means

Write down the expected shape before converting: number of columns, number of data rows, units and any grouped headers. Include repeated headers only once in the expected row count. Check what blank cells mean. They may mean “not reported” or “not applicable”. The source may not say. That record gives you a clear reference when the output differs from the page.

A correct table must preserve relationships, not just characters. If a value is accurate but belongs under the previous year's heading, the result is wrong. If an amount loses “thousands” from the caption, the result is misleading. A footnote may leave out one group. Remove the note and you change what the figures cover. Check those details before polishing column widths.

The GFM specification describes a table as “an arrangement of data with rows and columns”. It defines the pipe syntax used in many Markdown editors. That representation has limits: it is not a direct equivalent of every visual grid a PDF can display. You may need to simplify the structure. Explain that change clearly instead of claiming to keep every detail.

Start with one clean, rectangular section

For a whole file, use the PDF conversion workflow. For one visible table, select the header and a complete set of rows. Leave a little margin around the cells. Avoid including a nearby chart or unrelated paragraph, which can confuse the reading order. If the table spans multiple screens, whole-document reading is usually easier to review than overlapping captures.

Choose Markdown and inspect the source. Each row should have the intended number of cells. Check that the separator follows the header. A vertical bar inside a value may need escaping, depending on the renderer. Open the rendered preview too: a syntactically valid row can still carry the wrong meaning, so use both views together.

The pypdf text extraction explanation describes why PDF tables are difficult: visible positioning does not necessarily supply explicit table structure. A digital PDF can therefore need layout recovery even when no OCR is involved. Knowing this helps you choose a targeted review rather than assuming every problem comes from blurry characters.

Work through a small numerical example

Use this illustrative source table as a verification exercise. It is small on purpose. You can check every cell yourself. The figures are not customer data or observed converter results. Add the three values to get the expected total.

Table: illustrative order quantities used to demonstrate validation. Twelve plus seven plus eleven equals thirty units.

After conversion, count the three item rows, then compare each label and quantity. Add the quantities independently. If the result is 30, you have one useful check. Now inspect the row associations: swapping 12 and 7 would keep the total at 30 while making two rows wrong. This is why a sum alone cannot certify the table.

Next, inspect missing and signed values in your own source. A dash can mean no observation rather than zero. Parentheses can indicate a negative amount in some financial tables. A decimal comma can be misread as a separator. Preserve the source convention until you understand it, then explain any normalisation you make. Do not quietly “clean” data based on what seems likely.

How do I handle merged headers?

A PDF may group columns under a shared year or region. Basic pipe tables do not express those spanning cells in the same way. Use complete labels for the columns. For example, try “2025 net sales” and “2026 net sales”. Each column then makes sense on its own. Compare the flattened labels with the original before accepting them.

For row groups, repeat the group label in a dedicated column when that is clearer than relying on blank cells. A long note may apply to several rows. Put it just below the table and label it clearly. Keep the mapping explicit. A blank group cell can cause doubt. Does it use the label above, or is the value missing? Make the answer clear.

Some tables are better left as HTML, a spreadsheet or a companion image with a checked text summary. Do not flatten a complex matrix until it becomes a different dataset. If exact layout carries meaning, preserve the source and state what the text representation omits. State that limit clearly. It helps the reader know what the format can carry.

What happens when a table crosses a page break?

Page breaks create three risks: repeated header rows, duplicated overlap and missing boundary rows. Count source rows on both pages. Compare that count with the output. Leave repeated headers out of the data count. Check the last full row before the break and the first full row after it. Then look for a row whose label appears on one page and values continue on the next.

Imagine an illustrative supplier table continuing onto a second page with the same column names repeated. A conversion may place those names in the body. Removing that repeated row is reasonable after checking it is truly a header. Removing every row that resembles a heading is not. A genuine data row could contain similar wording, so make the decision from the source.

Keep the original page range in a note beneath the table. If another reviewer queries a value, they should be able to find it quickly. For downstream model use, the LLM preparation guide explains why the unit and source reference need to travel with each table rather than remain elsewhere in a long export.

Can I use the same output in Excel?

Markdown pipes are not usually the most direct spreadsheet input. Tab-separated text expresses cell boundaries more naturally for a plain-text paste. Choose the format for the destination and validate the cells there. The image-to-Excel guide covers number formats, leading zeroes and the distinction between a copied table and a native workbook export.

Do not assume formatting a cell as a number repairs a recognition error. It can make the wrong value easier to calculate with. First verify the characters and row association. Then apply data types, formulas and display styles. Keep a checked intermediate copy so you can trace a later spreadsheet discrepancy back to the conversion rather than redoing the whole exercise.

Save the meaning as well as the grid

Before sharing, confirm row count, column labels, units, signs, missing-value conventions and footnotes. Preview the exact destination. Keep the source reference and note any manual restructuring. A table should be readable without a private explanation from its converter.

Start with one representative table from a non-sensitive document using the PDF-to-Markdown guide. If it contains merged cells or a page break, include that difficulty in the trial. A carefully checked awkward example tells you far more about the fit of a workflow than a perfect export of an easy two-column list.

Questions, answered

Can a Markdown table contain merged cells?

Basic GFM pipe tables do not directly represent row or column spans. Flatten labels clearly or use a representation that preserves the needed structure.

Does a matching total prove my PDF table is correct?

No. Swapped values or offsetting errors can preserve a total. Check row labels, cell associations and values as well as arithmetic.

Should repeated page headers appear as table rows?

Normally not as data, but verify each repetition against the source before removing it. Record the page range for traceability.