Resume PDF reading order: columns, sidebars and text boxes

Reading order by layout and reader

Each fixture holds the same name, contact line, role, three bullets, skills and education. Only the layout changes.

Single column: one order everywhere

The single-column control came back line for line the same from all three readers: name, contact, heading, role, bullets, skills, education. That is the order a parser expects, and it is the order you wrote.

Two columns

PDF 32000 §14.8.2.3 (checked 19 October 2026) defines page content order as "determined by the sequencing of graphics objects within a page's content stream", and says that order "should normally (for Western writing systems) proceed from top to bottom (and, in a multiple-column layout, from column to column)". pdf.js follows the content stream, and Chromium wrote the left column first, so pdf.js read it cleanly.

pdftotext deliberately ignores the stream. Its manual says the default is to "'undo' physical layout (columns, hyphenation, etc.) and output the text in reading order", and with -raw it will "Keep the text in content stream order". On our page its reconstruction put SKILLS straight under EXPERIENCE and slotted single skills between the bullets.

Our checker used to group text by line position only, so it read across both columns: EXPERIENCE and SKILLS fused into one line, and each skill landed between bullet fragments. The date “2021 - Present” had wrapped in the narrow column, and the checker filed “Present” as the first bullet.

We fixed both on 20 October 2026 after these tests. The checker now looks for a clear gap that runs down the page between two blocks of text and reads one column at a time, and it puts a date end that wrapped onto its own line (“- Present”) back with the role. The text it shows still has “- Present” on a line of its own, because that is where the PDF put it.

Sidebars

A left sidebar is a narrow column that starts above the main one, so every reader that follows the page top-down meets it first. pdf.js and pdftotext both returned the full sidebar, contact details and skills, before the name, which came out on line 11. Our checker used to mix the two: it started with CONTACT, then alternated sidebar and body lines, and glued skills to the front of bullets.

Since our fix on 20 October 2026 the checker reads the two columns apart. It starts with the column that holds the name, set in the largest type, and reads the sidebar after it.

Text boxes

Our text-box fixture positions the email and phone in a box at the top right, written into the page after the body, which is how a floating box usually ends up in an export. Visually it sits beside the name.

Each reader put it somewhere different. pdf.js followed the stream and returned the contact details after the last bullet. pdftotext placed them after the name and title. Our checker returned the email first, then the name, then the phone, because the box sits a little higher on the page than the name's baseline. All three kept the text; none kept it where it appears. Our checker still filed the name, email and phone in the right fields.

Word's two-column sections

Word's own columns (Layout, Columns, Two) flow text from the bottom of the left column to the top of the right. In the DOCX that flow is one sequence of paragraphs, and our importer read it perfectly: 8 roles, 24 bullets, 5 skills.

Exported to PDF by LibreOffice 26.8.1.1, pdf.js and pdftotext still read column by column. Our checker used to pair each left-column line with the right-column line beside it, starting with the name joined to a bullet. Since our fix on 20 October 2026 it returns the same lines as pdf.js and files the same 8 roles, 24 bullets and 5 skills as from the DOCX.

What ATS vendors say about columns and text boxes

Greenhouse is one of the few vendors that publishes its list. Its support article on unsuccessful parses (checked 19 October 2026) names "Resumes that have a columned layout" and "Resumes with the name and contact information in the header, footer, or text box". The fixtures above show the mechanism: the text is there, but the order it comes back in depends on the extractor.

How to fix reading order

• Use one column for everything a parser fills in: name, contact details, job titles, employers, dates and bullets.
• Put contact details in the body as ordinary text under your name, not in a text box or a sidebar.
• List skills as a comma-separated line or short list under a SKILLS heading in the same column.
• Keep dates on the same line as the role, and make sure the line doesn't wrap at any width you export.
• Test the export in two readers. If both return your sections in the order you wrote them, the layout is doing its job.

How we tested

We built every fixture from the same fictional one-page resume, changing one thing at a time. PDFs come from Chromium 153.0.8010.12 (printed through Playwright 1.63.0) and from LibreOffice 26.8.1.1 converting our DOCX files, the way Word users export. Each file was read three ways: pdf.js 6.3.289 getTextContent, poppler pdftotext 26.10.0 in its default mode, and the importer the ATSPrep checker runs in your browser. DOCX files have no PDF text layer, so only our importer reads them. The code blocks on this page are the readers' output, copied by script; private-use and control characters are written as [U+XXXX] because they would otherwise be invisible.

These are three common open readers, not any employer's applicant tracking system. Commercial parsers use their own extractors, so treat a failure here as a risk to remove, not a prediction of what a specific system will do.

Common questions