Passmatch
All guides

The complete guide to an ATS-friendly resume

By the Passmatch team5 min readUpdated 28 July 2026

A rejected resume never tells you why. Between the moment you click apply and the moment a human being reads you, your document passes through software that turns it into data. If that conversion fails, the content stops mattering: what gets judged is not your career, it is whatever the machine managed to extract from it.

This guide explains the mechanism, step by step. It contains no market statistics: this field is saturated with them and most circulate without a verifiable source. Everything below is either a property of the file formats, a property of text extraction, or something Passmatch does and shows you.

What an ATS is, and where it sits

ATS stands for Applicant Tracking System. A company uses one to receive applications, store them, search them and follow each file through to a decision. It is first and foremost a filing tool, not a judge.

But to file and retrieve applications, an ATS has to understand them first. It does not keep your PDF the way a drawer keeps a photograph: it extracts a name, an email address, roles, dates and skills, and fills in a record. That record — not your document — is what the recruiter will read, filter and compare.

This distinction is the heart of the matter: your resume is not read, it is converted. Anything that did not survive the conversion does not exist for the rest of the process.

Step one: your document becomes text again

A PDF is not a text document. It is a description of a layout: instructions saying place this character at these coordinates, in this font. Extracting text from a PDF means reading those instructions back and trying to reconstitute words, then lines, then a reading order.

That reconstitution is an inference, not a reading. It works very well on a simple layout and degrades as soon as the page gets inventive. A DOCX file is friendlier — it carries a real paragraph structure — but it brings traps of its own, tables and text boxes chief among them.

There is one case where extraction does not degrade but fails outright: a document with no text layer. A scanned, photographed or image-exported resume contains pixels and not a single character. There is literally nothing to extract. Without an optical recognition step, the record comes back empty.

Step two: the text becomes fields

Once the text is out, it has to be cut up. The parser looks for landmarks: section headings it recognises, date patterns, email and phone formats, sequences that look like role, employer, period.

Those landmarks are conventional. A parser recognises Work experience because that heading is unremarkable, and hesitates in front of My journey, Where I grew up or Highlights. The vocabulary that charms a human reader takes away the foothold the software needs.

Order matters too. A role whose title, employer and dates end up scattered across three distant areas of the page has little chance of being tied back to one single entry. It dissolves into fragments.

What breaks the reading, concretely

The causes below are not forum superstitions. Each one follows directly from the two steps above.

  • Two columns. Extraction follows the file's internal order, which is not necessarily the visual one. A columned page can come back as interleaved lines, where a date from the left column lands in the middle of a skill from the right.
  • Tables. They are built for the eye, which reads in two dimensions. Extracted text has only one: the grid vanishes and all that remains is a run of cells laid end to end.
  • Headers and footers. Many resumes put the name, phone number and email there. Depending on the tool those areas are handled separately, repeated on every page, or dropped — and it is the candidate's identity that lives there.
  • Text inside an image. A title banner exported as a PNG, a logo containing your name, a skills chart: all of it is invisible to extraction, however crisp it looks on screen.
  • Icons and pictograms. A little envelope in front of your email is meaningful to you; to the parser it does not say this is an email address. An explicit label does the job the icon does not.
  • Unusual fonts and ligatures. Some encodings come back with substituted or fused characters. The word looks right on screen and is damaged once extracted.
  • Invented section headings. See above: the parser does not guess, it recognises.

None of this is a matter of graphic taste. A resume can be plain and unreadable to a machine, or polished and perfectly extracted. What counts is how the content is laid down in the file, not how elegant it looks.

What an ATS does not do

As useful as knowing what it does is knowing what it gets wrongly blamed for.

  • It does not give you a universal grade. There is no standard ATS score that follows your resume from one company to the next. What exists are filters and searches, defined by each recruiter, run against the extracted record.
  • It does not reject on its own. An ATS sorts, filters and presents; the decision stays with the recruiter who set the criteria.
  • It does not reward a particular template. No layout is certified. What gets rewarded is a document whose extraction loses nothing.
  • It does not miss hidden white text. Stuffing a resume with invisible keywords stays perfectly visible to extraction, since extraction is exactly what reads it — so it shows up, in plain sight, in the record.

Check rather than believe

The real trouble with this subject is how well it lends itself to unverifiable advice. Avoid columns is good advice, but until you see what a parser actually pulls out of your document, you are applying a recipe without measuring a result.

That is the principle behind Passmatch: your document is genuinely re-read by deliberately crude parsers, and the text they pull out is shown to you raw. It is not an opinion, it is a reading. You see what survived and what disappeared.

Once that is established the rest is mechanical: fix what gets lost, check again, repeat. The practical guide picks up exactly there, as a list of actions.

Written by the Passmatch team. We only publish what we can verify: no market statistic without a source, and no behaviour attributed to software we do not operate.