Can ATS read a two-column resume?

What does an ATS actually do with my PDF?

It reads it twice, in a sense. First it pulls the raw text out of the file. Then it tries to sort that text into fields: your name, your contact details, each job title, each company, each set of dates, your skills. That second step is called parsing, and it is where recruiters get the tidy profile they search and filter on.

Here is the catch. A PDF does not store paragraphs. It stores letters and words with coordinates, like "put these characters at this spot on the page." There is no built-in rule that says "finish the left column before starting the right one." The extractor has to rebuild reading order from positions alone.

Some extractors detect columns well. Some read straight across the page, line by line, the way a photocopier scans. You do not get to pick which one a given employer runs, and you cannot see it from the outside. What you control is how much guessing your file demands.

What does a scrambled resume look like?

Easier to show than tell. Below is a small two-column resume. Flip between the view you see and the two ways software can read it back out.

Look at the row-by-row version again. Nothing is missing. Every word you wrote is there. It is just in an order that breaks meaning: a skills line welded to an achievement, a section heading stuck to the middle of a bullet. A human could untangle it with effort. Software filling in a "skills" field does not untangle; it guesses, and a wrong guess is quiet. You never see the mangled profile. The recruiter does.

So is it the columns, or how they are built?

How they are built. The same visual layout can come from very different files.

• Real text columns. The word processor's own column feature, or a design tool that exports text in a sensible order. Extractors usually read one column, then the next. This is the version in the demo that comes out whole.
• A table with invisible borders. Very common in templates. Each cell is its own box, and text tends to come out row by row across cells. That is the version that interleaves.
• Text boxes and shapes. Floating objects positioned on top of the page. They live outside the main flow of the document, so they can land at the very end of the extracted text, out of order, or not at all.

You usually cannot tell which one you have by looking. Two resumes that look identical on screen can paste out completely differently. That is why the test below matters more than any rule of thumb.

Why do tables and text boxes cause so much trouble?

Because they were built for looks, not for reading order. A table says "these cells sit side by side." It does not say "read all of the left cells first." When a single bullet wraps onto three lines in the right cell and the left cell holds a skills list, a row-by-row read stitches them together line by line. Nested tables (a table inside a table, which many templates use for the header) make it worse.

Text boxes are a different failure. They float. The document treats them as separate objects attached to the page, not as part of the text. Your carefully placed "Skills" box in the corner can come out after your education, or vanish from the extracted text entirely.

What about headers, footers, icons and graphics?

Each of these breaks in its own way. None of them is worth the risk on the page that matters most.

• Headers and footers. The page header (the strip a word processor repeats on every page) is a favorite place to put a name and email. Some parsers skip header and footer regions, or read them last. If your contact details live there, they are the first thing at risk.
• Icons instead of labels. A little phone glyph or envelope glyph means nothing as text. At best it vanishes. At worst it comes out as a stray symbol in front of your number.
• Skill bars and rating dots. A row of filled dots next to Python is a shape, not text. The parser sees the word Python and nothing else. Recruiters do not trust these anyway.
• Text inside images. If your name or headline is part of a picture, a text extractor does not see it. It is pixels.
• Decorative fonts. Some fonts store letters in unusual ways, and the text comes out as gibberish or with letter pairs like "fi" missing. Standard fonts avoid this.

How do I check my own resume right now?

Run a paste test. It is not the exact engine any employer uses, and it does not claim to be. It is a cheap proxy: if a plain copy of your file comes out scrambled, a parser has work to do too.

1. Open the exact PDF you send to employers. Not the source document, the exported file.
2. Select all the text in the PDF viewer and copy it.
3. Paste it into a plain text editor. Notepad on Windows works. On a Mac, open TextEdit and choose Format, then Make Plain Text, before you paste. A blank plain text file in any code editor works too.
4. If your resume started life in Word, run a second check: Save As, then choose Plain Text (.txt), and open that file.
5. Read the result top to bottom, slowly, as if you were software trying to fill in a form.

While you read, ask these questions:

• Is your name the first thing in the file?
• Are your email and phone number there at all, spelled out as plain text?
• Does each job title sit right next to its company and its dates?
• Does every bullet come out whole, or is it split by lines from another column?
• Is any section missing, duplicated, or dumped at the very end?
• Do you see stray symbols, boxes, or broken words?

If the answers are all clean, your two columns are fine. Keep them. If anything is wrong, the next section is your repair list.

The test came out messy. What do I fix first?

Fix the things that carry your identity and your history first: contact details, then job titles and dates, then everything else. Each fix below trades a fragile structure for plain text in reading order.

Notice the last one. Creative headings read nicely to a person and confuse software that looks for familiar section names. "Experience," "Education," and "Skills" are boring on purpose. Boring is how the parser knows where it is.

After each fix, export a fresh PDF and paste it again. The test is fast enough to run after every change.

Is there a safe layout checklist?

There is a low-risk one. Nobody outside an employer's IT team can promise how a specific system reads a specific file, so treat this as reducing guesswork, not eliminating it.

• Contact details in the body of the page, as plain text, never only in the header or footer.
• Standard section headings: Experience, Education, Skills, Projects.
• No tables for layout, and no text boxes or floating shapes holding real content.
• No text inside images, and no icons standing in for words.
• Skills written as words, not bars, dots, or charts.
• A standard font, exported to PDF from the source document, not printed to PDF from a screenshot.
• Job title, company, and dates on lines next to each other, in the same order for every role.
• If you use two columns, they pass the paste test with every bullet intact.

Should I just give up on two columns?

Not if your file passes the test. A clean two-column resume is a reasonable choice, especially when a short sidebar of skills and links frees up room for your experience.

But if it fails, and the fix means rebuilding a template you do not control, switch to a single column. You lose very little. A person reading a single-column resume has no trouble with it, and a parser has the least possible reordering to do. The design budget you gave up was mostly decoration.

If you want a fast way there, the free Resume Blox editor lays the page out section by section, top to bottom, with no sidebar and real, selectable text. You write every word yourself; the editor handles the layout. Run the paste test on its PDF too, the same as any other.

Open your PDF right now. Select all, copy, paste into a plain text file, and read it like a machine would. If it reads like your resume, you are done worrying about columns. If it reads like the scrambled view in the demo, you just found the problem nobody was going to tell you about.