Resume Tables Under Extraction: Same Problem, Milder Form

Tables trigger the same grouping mechanism as columns

A PDF table is not a table in the HTML sense. There is no grid structure, no cell boundaries, no row or column metadata. There are positioned text fragments, the same as everywhere else in the document. A reader groups them by vertical proximity, and if two fragments from adjacent cells share a vertical band, they fuse.

This is the same mechanism that causes two-column interleaving. The difference is not in the physics of how it happens. It is in what sits beside what.

In our study, 108 files were generated with pdf-lib and read back with PDF.js using the same line-grouping the product ships. Table-grid resumes used a simple layout: dates in the left cell, job details in the right cell, one row per role.

What table extraction actually produces

Here is verbatim output from the table-grid condition. The welded lines are highlighted, and the contrast with the two-column output is immediate.

The date and the job title fused into one line: "2022 - Present Senior Backend Engineer, Northwind Systems". That is clumsy, but a human can still read it, and a parser looking for a date next to a role still finds both. Compare that with the two-column case, where a phone number fused with a bullet about Kubernetes.

The difference is adjacency. A table row places a date beside the job it belongs to. A two-column layout places a skills list beside experience bullets that have no relationship to it. When unrelated content fuses, the output is nonsense. When related content fuses, the output is merely compressed.

How tables compare across every metric

Table grids recovered 97.6% of intended words, effectively the same as the two-column layout at 97.9%. Both are close to the 100% control.

Where they separate is in order and welding. Tables scored 93.4% reading-order fidelity versus 83.6% for two columns. That makes the table grid the best-performing multi-region layout in the study. Welding was 24.1% versus 30.5%, lower but still non-zero.

Block integrity remained at 100% for both layouts. The sections survived as coherent blocks. The interleaving happened at the line level, not the section level.

Why related-cell welds are less harmful

A welded line is still a welded line, but not all welds are equally damaging. When a date fuses with its job title, the information that belonged together is still together. A parser trying to associate "2022 - Present" with "Senior Backend Engineer" can still find both tokens on the same line, in the right order.

When a phone number fuses with a bullet about Kubernetes, the information is not merely compressed. It is misattributed. A reader looking for contact details near a name finds them in the middle of a work achievement instead.

This is why the welding metric alone does not capture the severity. The same percentage of welded lines can mean very different things depending on whether the fused fragments belong together or not. In the table layout, they do. In the two-column layout, they often do not.

Which table designs carry more risk

Not all tables are the same. The condition we tested placed dates beside their corresponding roles, a narrow left column and a wide right column. That is the most common table use in a resume, and it is relatively safe because the adjacent cells are related.

The risk increases when a table is used to build a layout that places unrelated content side by side. A full-height skills column built as a table cell, sitting beside experience bullets, would behave much more like the two-column layout. The welding rate would approach the two-column numbers, and the welds would join unrelated content.

The practical distinction is not between tables and non-tables. It is between layouts where adjacent regions contain related content and layouts where they do not. A date aligned with its job is low risk. A full-height skills rail is not.

• A table aligning dates with roles is a mild risk: welds join related content.
• A table used as a two-column layout engine carries the same risk as explicit columns.
• The deciding factor is what sits beside what, not whether the structure is technically a table.

Practical guidance for table-based resumes

If you use tables to align dates with job titles, the measured risk is real but moderate. The output is clumsy rather than incoherent, and reading order is better preserved than in any other multi-region layout we tested.

If you use tables to build a full two-column layout with a skills rail beside experience, you get the two-column problem, not the table problem. The structure is a table, but the layout is side-by-side unrelated content, and the extraction will behave accordingly.

The safest option remains a single column. But if you prefer a date-aligned table layout, the data suggests it is a smaller risk than the usual advice implies, provided the adjacent cells contain content that belongs together.

• Date-aligned tables: moderate risk, legible welds, best multi-region order score.
• Full-layout tables acting as columns: same risk as two-column designs.
• Single column remains the zero-risk baseline.
• Test the result by pasting extracted text and checking whether welded lines are still readable.

Study limits

The corpus is synthetic: all 108 files were generated with pdf-lib rather than collected from real applicants. This means every variable is controlled and the intended text is known exactly, but it also means no one's personal data is involved.

One reader was tested: PDF.js, the same library the X-ray runs. Employer systems use different extractors and may produce different results. Findings describe how these formatting choices behave under extraction, not how any particular company screens.

The table layout we tested was a simple date-role grid. More complex table designs, such as nested tables, merged cells, or tables spanning the full page height, were not tested and may behave differently.