Blog

How resume parsing works and why your layout breaks it

The actual mechanics of resume parsing, and the simple test that shows you what a machine sees.

You spend hours on a resume, line up the spacing, pick a clean two-column template, and send it off. Then it goes quiet. Understanding how resume parsing works explains a lot of that silence. Before any recruiter reads your name, a piece of software pulls the text out of your file and tries to sort it into fields. When that step goes wrong, it stores a garbled version of you, and you never see it happen.

What resume parsing actually does

Parsing is the step where the application system reads your uploaded file and turns it into structured data. Not a picture of a resume, but labeled fields: name, email, phone, each job title, each employer, dates, education, skills.

It happens in roughly three moves.

  • Text extraction. The software pulls the raw characters out of your PDF or Word file. This is just text, stripped of most of your visual layout.
  • Reading order. It decides what order those characters go in, usually top to bottom and left to right, the way text physically sits in the file.
  • Field mapping. It looks for patterns and drops the text into named fields. An email is anything shaped like a thing@thing.com. A job is a title, a company, and a date range sitting near each other. A new section starts at a familiar header like “Experience” or “Education”.

When your layout is plain and the reading order is obvious, this works fine. Your titles land under work history, your dates line up, and the recruiter sees a clean record. The trouble starts when your design fights that order.

Why columns and text boxes scramble it

The parser does not see your resume the way you do. It does not know that the left column is a sidebar and the right column is your work history. It reads characters in the order they exist in the file, then guesses at structure.

A few common layout choices cause most of the damage.

  • Two columns. This is the big one. The parser can read straight across both columns instead of down each one. Your skills list gets stitched into the middle of a job description, and the result reads like nonsense.
  • Tables. A table that holds your dates or titles can get read cell by cell in an order you did not intend, so a date ends up detached from the role it belongs to.
  • Text boxes. Text placed inside a floating box or shape often sits outside the normal flow. Some parsers read it last, some skip it. Either way, content you thought was prominent goes missing or lands in the wrong place.
  • Headers and footers. Some parsers ignore the header region of a document. If your name and phone number live up there, they can vanish from the record entirely.
  • Graphics with text inside. A skills chart, a rating bar, a logo with words baked into the image. The parser reads pixels, not the text, so it sees nothing.

None of this gets you formally rejected by the machine. It quietly stores a worse version of your history. A recruiter opens a record where your last two roles are missing or your title reads as part of a sentence, and they move on. That is a hard way to lose a strong application, because nobody tells you it happened. The fixes overlap heavily with ATS resume formatting that survives parsing.

The 60-second plain text test

You do not need special software to see what a parser sees. There is a quick test that approximates it well.

  1. Open your resume file.
  2. Select everything and copy it.
  3. Paste it into a plain text editor. TextEdit in plain text mode, Notepad, or any code editor works. The plainer the better.

Now read what landed there.

  • Are your job titles, companies, and dates still grouped together, in order?
  • Did your two columns flatten into a single readable stream, or did the lines interleave into garbage?
  • Did your name and contact details survive?
  • Did anything disappear, like text that was inside a box or a graphic?

What you see in that plain text window is close to what the parser feeds into the fields. If it reads cleanly to you, it reads cleanly to the machine. If it reads like scrambled fragments, that is the version sitting in the company’s system.

This is also a good gut check before you trust any template. A layout can look polished in the preview and fall apart in plain text.

What to fix when the test fails

If the paste came out messy, the repairs are usually small.

  • Drop to a single column. One main column, top to bottom, is the safest layout. It is also the easiest for a tired recruiter to skim.
  • Pull contact details into the body. Put your name, email, and phone in the normal flow near the top, not in a header or footer region.
  • Remove text boxes and tables. Lay out your roles with plain headings and bullet points. Let the document flow do the structure.
  • Cut text baked into graphics. If a skill or rating only exists inside an image, write it out as real text instead.
  • Use standard section headers. “Experience”, “Education”, “Skills”. Clever section names can confuse the field mapping.

Run the plain text test again after each change. When the pasted version reads in the right order with nothing missing, the machine is getting an accurate picture of you. For the deeper view of what the system does after parsing, see how an ATS reads your resume.

A clean layout is one half of the work. The other half is making the words on the page match how the employer describes the job. Linora pulls roles straight from company career pages, reads the posting, and hands you a tailored resume draft that mirrors that language in a plain, parser-friendly format. You review every line and submit it yourself. See how it works at getlinora.com.