Why Your Two-Column Resume Breaks

Open any resume template gallery and half the designs are two-column. A narrow sidebar down the left with contact details, skills, and maybe a language bar; a wide main column on the right with your experience. It looks organised, modern, and expensive.

It is also the layout most likely to come out of a parser as nonsense. This post explains precisely why, covers the two close relatives of the problem — tables and text boxes — and gives you the layouts that survive.

The reading-order problem

A parser’s job in the extraction step is to turn positioned text fragments back into a sequence. With nothing else to go on, the natural heuristic is: sort roughly by vertical position, then by horizontal position. Read across, then down. Exactly how you were taught to read.

That heuristic is correct for a single column and wrong for two, because in a two-column layout the text that is visually next is not the text that is physically to the right. Your eye knows the sidebar is a separate track. The extractor, working from coordinates, often does not.

So a document that looks like this:

SKILLS | EXPERIENCE Python | Senior Analyst, Northwind Ltd. SQL | Jan 2021 – Mar 2024 Tableau | Rebuilt the monthly reporting pipeline.

can extract like this:

SKILLS EXPERIENCE Python Senior Analyst, Northwind Ltd. SQL Jan 2021 – Mar 2024 Tableau Rebuilt the monthly reporting pipeline.

Read that stream as a machine would. Where does the Skills section end? Is “Python” a skill or part of a job title? Nothing in the text says. The heading SKILLS is now immediately followed by the heading EXPERIENCE, which suggests the skills section is empty, and the actual skills have been absorbed into your work history.

Nothing was deleted. The structure was.

Why it’s inconsistent — and why that’s worse

Not every parser gets this wrong. Better extractors do column detection: they look for a vertical gutter of whitespace running down the page and treat the regions on either side as separate blocks. When that works, a two-column resume extracts perfectly.

So your file might sail through one employer’s system and scramble at the next. That inconsistency is precisely why “it worked fine when I tested it” isn’t reassurance. You are not sending your resume to one parser; over a job search you are sending it to a dozen, of varying vintages, configured by different people.

Single-column layouts don’t have a good case and a bad case. They have one case.

Tables: the same problem, dressed up

Plenty of “single-column” templates are secretly tables. A common pattern puts each job in a two-cell row — dates on the left, description on the right — or lays a skills section out in a neat three-by-four grid.

A table is a grid of positioned cells, which is a column layout by another name. Extraction may walk it row by row, cell by cell, or in a completely different order depending on how the table is stored. Text that reads as a tidy grid can emerge as a run-on line, or with the contents of the right column arriving before the left.

There’s also a subtler failure. In a table-based job entry, the date range lives in a different cell from the job title. Some field matchers associate a date with the nearest preceding title in the text stream. If cell order puts the date first, it may get attached to the previous job — so a role you held for three years shows up with the dates of the one before it.

Use a table for tabular data. A work history is not tabular data.

Text boxes: the invisible ones

Text boxes are the most dangerous of the three, because they can vanish outright.

In a word processor, a text box is a floating object anchored to the page rather than part of the main text flow. Some extractors read the main flow and skip floating objects. If your name and contact details are in a text box at the top of the page, the parsed record can come back with no name and no email — from a document where those details are, to your eye, the largest thing on the page.

The same applies to shapes with text in them, callout boxes, and sidebars implemented as floating frames rather than as real columns.

Headers, footers, and graphics

Two more constructs deserve a mention in the same breath:

• Page headers and footers. Same story: a separate region, sometimes skipped. Never put contact information there. A page number is fine; your phone number is not.
• Images and text-as-graphics. A logo, an icon, a skills radar chart, a “proficiency” bar, or a resume exported as a picture. Extraction pulls out text; it does not read pictures. Whatever is in there contributes nothing at all. Skill bars are particularly wasteful — they take up real space and convey, to the parser, zero information. Write “Advanced” or “3 years” as words instead.

What to use instead

The fix is not ugly. It’s just structural.

One column, full width, top to bottom. Everything in the main text flow. This alone eliminates most parsing failures.

Real headings, not layout tricks. Make Experience an actual heading — bold, slightly larger, with space above. That’s a visual separator a human reads instantly and a parser recognises as a section boundary.

Job entries as consecutive lines. Title and employer on one line, dates on the same line or the line directly below, then bullets. No cells, no columns, no floats.

Contact block in the body. First lines of the document, in the normal flow.

Skills as a written list. Comma-separated, or bulleted, in plain text. If you want to convey level, use words.

Design with type and space. You still have weight, size, spacing, rules, and one accent colour to work with. That is more than enough to produce something that looks considered. The templates that parse best are usually the ones a typographer would have chosen anyway.

Confirm it in two minutes

Select all the text in your resume, copy it, and paste it into a plain text editor.

Read the result top to bottom. If your sections are intact and in order, your layout is safe. If the sidebar has been shuffled into your job history, you’ve just watched the failure happen — and you now know exactly which construct to remove. There’s a fuller version of this check in how to test your resume like a parser would.