What actually happens to your resume inside an ATS

There is a story that goes around: an algorithm reads your resume, gives it a score out of 100, and bins you if you fall below the line. It is a satisfying story because it makes the silence somebody else’s fault.

It is also mostly wrong, and believing it sends people to fix the wrong thing.

What does an ATS actually do with your resume?

An applicant tracking system is a database with a form in front of it. Its main job is to take an unstructured document, your PDF, and turn it into structured fields: name, email, current title, employers, dates, education, skills. Recruiters then search and filter those fields.

So the sequence is:

1. Your document is parsed into fields.
2. A recruiter filters or searches on those fields.
3. The rows that survive get opened by a human.

There is no secret score in step one. There is something worse. Anything the parser fails to read does not become a field, and a field that does not exist cannot match a search. You are not rejected. You are invisible, which looks identical from your side.

Where does resume parsing actually fail?

The failures are boring and specific.

Multi-column layouts. The designer’s favourite resume, skills in a narrow left rail, experience on the right, is read by many parsers straight across the page. Your left-column heading gets glued to the first line of your right-column job. The result is not wrong so much as scrambled.

Text inside images. A skills graphic, a logo bar, a chart of “proficiency” dots. To a parser this is a blank area. Everything you put in it is gone.

Unusual date formats. “Mar ’23 to present” or “2023.03” can fail where “March 2023 - Present” succeeds. When dates fail, tenure fails, and a filter on “3+ years current role” quietly drops you.

Headers and footers. Some parsers ignore them entirely. If your contact details live only in the header, you can be parsed into a record with no email address.

Tables. A table that renders neatly can serialise into a single run-on line, or into cells read in an order that makes no sense.

Creative section names. “Where I have been” instead of “Experience”. A human gets it instantly. A parser matching known section headings does not.

Notice what is not on the list: font choice, one page versus two, whether you wrote a summary. Those are human-preference arguments, not parsing failures.

Do keywords actually matter?

Keywords matter, but not the way the myth says. A recruiter searching for a skill will search the words their team uses. If the posting says “Kubernetes” and your resume says “container orchestration”, a search on Kubernetes does not return you. That is not an algorithm judging your worth. It is string matching doing exactly what string matching does.

The fix is not to stuff a list of every technology you have heard of at the bottom of the page. It is to say the specific thing you did, in the words the field actually uses, in the place where you did it. “Ran the Kubernetes migration for our payments service” beats a keyword salad, and it survives a human reading it afterwards, which the salad does not.

And the line you should not cross: never claim a skill you do not have to beat a filter. It gets found in the first technical conversation, and it costs you the one thing that is genuinely scarce, which is people who think you are honest.

How do you check your own resume in ten minutes?

You do not need a tool for the first pass.

1. Open your resume PDF in a plain text viewer, or copy all the text and paste it into an empty text file.
2. Read what comes out.

That paste is roughly what the parser sees. If your job titles are welded to skill names, if the dates are missing, if a whole section is absent because it was an image, you have found your problem and it took ten minutes.

Then check one more thing: pick the last three roles you applied to and find the five words the posting repeats. Search your resume text for those five words. If most of them are absent, you were not filtered out for being unqualified. You were absent from the search.

What does fixing this actually get you?

Fixing parsing gets you into the pile. It does not get you out of it. If four hundred people applied and eighty of them parse cleanly, you have moved from invisible to one of eighty, which is progress and is not an interview.

That is why this is one part of a bigger picture. The other parts, including the ones that are not about your document at all, are in why you are not getting interviews.

Horabbit does this parse check on your actual resume, in your actual target market, and then keeps going: which companies you have a real chance at, and who inside them makes the call.