How to write a resume that software reads correctly

We parse thousands of resumes. These are the things that actually break, in order of how often we see them, and what to do instead.

21 September 2026 · 6 minute read

Most advice about writing for applicant tracking systems is folklore passed between candidates, and a fair amount of it is wrong. What follows comes from the other side: we parse resumes continuously, and these are the things that actually break.

One fact explains nearly all of this

Every system that reads your resume starts by throwing away how it looks. A PDF goes through a text extractor, a Word file gets its document body pulled out of the archive, and what comes back is a single run of plain text. No columns, no fonts, no boxes, no alignment. Whatever survives that flattening is your resume as far as any software is concerned.

Almost every real failure below is a consequence of that one step, which is also why the usual advice to “use an ATS-friendly template” is unsatisfying. The useful question is not which template. It is what your document becomes when the layout is removed.

The scanned PDF, which is the worst case

A PDF exported from a word processor contains real text. A PDF that is a photograph or a scan of a printed page contains an image, and no text at all. Extraction returns nothing, so the file has to go through optical character recognition, which is slower and guesses at anything faint, rotated or unusually set.

Candidates rarely know which they have, and the file looks identical either way. The check takes five seconds: open it and try to select a line of text with your cursor. If nothing highlights, every system that reads it is reading a picture. Export a fresh PDF from the original document rather than sending a scan or a phone photo.

Two columns, which is the most common

The sidebar layout, skills and contact details down one side, experience down the other, is the single most popular resume design and the one that degrades worst. Extraction returns text in document order, not visual order. Depending on how the file was produced, the sidebar can arrive interleaved line by line with your experience, or dumped in one block far from the content it sat beside.

The damage is not that the words go missing. It is that they detach from their meaning. Dates separate from the roles they belonged to, so a parser sees a list of jobs and a separate list of years and has to guess the pairing. Guessed wrong, your eight years read as three. A single column removes the problem entirely.

Tables, text boxes and headers

A table flattens into a sequence of cell contents, and the relationship between a header and the cells under it is usually the first casualty. Experience laid out as a grid can come back as a stream of fragments.

Text inside a text box, or in the document header and footer region, is handled inconsistently: sometimes pulled in at the wrong position, sometimes dropped. Putting your name, email or phone number there is a genuine risk of arriving without contact details.

Anything that is a picture of information

Skill bars, five-star proficiency ratings, donut charts of language ability, icons standing in for a phone number: these carry no text. A rating of four out of five stars for Python extracts as nothing whatsoever. You have spent a line of your resume communicating exactly zero to the first several readers.

Write the skill as a word. If proficiency matters, say it in words a person would use, or better, let the project that demonstrates it say it for you.

Write what you did, not what you were responsible for

This is the one that is not a formatting problem, and it matters more than the rest.

“Responsible for various modules of the application” is a sentence with no content. It is true of every engineer who has ever held a job, which means it cannot distinguish you from any of them. Systems that rank you against roles have nothing to work with, and neither does a person.

“Built the payment reconciliation service in Go, handling around 40,000 transactions a day” names the thing, the tool and the scale. That sentence can be matched against infrastructure roles, payments roles, Go roles and backend roles, none of which needed to appear as a keyword. Specifics are not decoration. They are the surface anything reading your resume has to work with.

What does not matter as much as you were told

File format, within reason. PDF and DOCX are both read reliably when they contain real text. The format is far less important than whether the layout survives being flattened.

Keyword stuffing. Repeating a skill eight times, or pasting the job description in white text, does not help in any system worth applying through and reads as dishonest to the person who eventually opens the file. Systems that understand meaning rather than counting words are unaffected by it, and systems that count words are not the ones making the final decision.

Length, mostly. Two pages that say what you did beat one page that does not. The reason short resumes are recommended is that length usually correlates with padding, not because a page counter is rejecting you.

The version to send

A single column. Real selectable text, exported rather than scanned. Contact details in the body. Dates next to the roles they belong to. Skills written as words. Sentences that name what you built and what happened as a result.

That document is read correctly by software, and it is also just a better resume for the human who reads it after.