What an ATS actually does with your resume

There is a small industry built on making job seekers afraid of applicant tracking systems. You have probably seen the claim that 75 percent of resumes are rejected by a robot before a human sees them. That number gets repeated everywhere and has no reliable source behind it. The reality is less dramatic and more useful to know.

What the system is actually for

An applicant tracking system is a database. Its main job is to store applications, let a recruiter search them, and track each candidate through the hiring stages. When your resume arrives, the system parses it: it tries to pull your name, contact details, employers, job titles, dates, education and skills into structured fields.

That parsing step is where resumes genuinely get damaged. Not by a score, but by information landing in the wrong field or disappearing entirely. A recruiter then searches for candidates with, say, three years of Java experience, and you are not in the results because your job titles never parsed.

What actually breaks parsing

• Text inside a text box or a shape. Many parsers read the document body and skip these entirely, so a name and phone number in a designed header block can vanish.
• Multi-column layouts where the columns are made with a table. Some parsers read across the row rather than down the column, which turns your resume into interleaved nonsense.
• Headings the parser does not recognise. Call the section Professional Journey and it may not map to Experience. Call it Experience and it will.
• Dates in inconsistent formats. Mixing 03/2023, March 2023 and 2023 in one document makes duration calculation unreliable.
• Contact details in the page header or footer. Some parsers never read those regions.
• Skills shown only as a graphic, a rating bar or a word cloud. There is no text to extract, so the skill is not in the database.

What does not break parsing

Colour is fine. A sensible accent, a coloured section rule and a tinted header band are all just formatting on text and parse normally. A single-column layout with clear headings, a PDF exported properly from a word processor, and a bulleted list are all fine. Most of what makes a resume look designed is not the problem. What causes trouble is structure that hides text from the parser.

Keywords, without the superstition

Recruiters search the database using the terms in the job description. So the terms in the job description should appear in your resume, where they are true. That is the whole of it. There is no threshold to hit and no benefit to stuffing a white-text keyword block at the bottom of the page, which is both detectable and a fast way to be removed from consideration.

The practical version: if the posting says Spring Boot and you have used Spring Boot, write Spring Boot rather than just Java. If it says accounts payable and you have done accounts payable, use that phrase rather than a synonym. Include the expanded form of an acronym the first time, so both forms are searchable.

The thing that actually decides it

Once your resume has parsed cleanly and turned up in a search, a person reads it. That person spends a few seconds deciding whether to keep reading. No amount of parser optimisation helps at that point. What helps is a resume that says what you can do, for the role you are applying to, with evidence attached.

Getting past the system is a formatting problem, and it is solvable in an afternoon. Being chosen once you are past it is a writing problem, and that is the harder half.