Why Your Resume Vanishes Before a Recruiter Sees It

You submit. The page says "Thanks, we'll be in touch." You're never in touch.

Here's what actually happened: a piece of software opened your file, tried to read it, fumbled some of the pieces, slotted what it could into a database row, scored that row against the job, and dropped your application somewhere near the bottom of a sorted list. No recruiter ever looked at it.

The software is an applicant tracking system — an ATS. Greenhouse, Workday, Lever, Taleo, iCIMS, BambooHR. Every mid-size company runs one. Most large companies run two. And every one of them parses your resume before any human eye does.

The frustrating part: there's no rejection email. There's no "your formatting broke us." Your file just sinks. Most candidates assume they weren't qualified. Plenty of them were.

What an ATS actually does with your file

When you upload resume.pdf, the system runs roughly this sequence:

1. Extract text. It pulls the raw characters out of your PDF or DOCX. This is the step where most resumes lose information.
2. Parse sections. A model — sometimes regex-based, sometimes ML-driven — tries to identify "Experience," "Education," "Skills," and so on.
3. Pull entities. Inside each Experience block, it tries to recognize a job title, a company name, a start and end date, and bullets.
4. Match against the JD. The system scores how well your extracted skills, titles, and dates line up with the role's requirements.
5. Sort. Recruiters see a list, ordered by score, often with a numerical match next to each name.

Step 1 is where the silent failures live. If the parser can't extract clean text, every step downstream is working from a half-empty record.

The three formatting choices that get resumes shredded

1. Two-column layouts

Designer templates love them. A skinny left column for skills and contact info, a wide right column for experience. They look polished.

The ATS reads top-to-bottom, left-to-right, like a person — but it doesn't always understand columns. Some parsers read across both columns line by line, so your resume comes out as "Skills · Python · Senior Engineer at Stripe · Email: jane@..." — one garbled blob. Others read the entire left column, then the entire right. Either way, your section structure is gone.

Fix: Use a single column. Save the two-column design for the version you hand to a recruiter at a meetup.

2. Text trapped inside images

Headshots. Logos. Decorative banners. "Skill bars" rendered as graphics. The ATS sees a rectangle of pixels and moves on. Anything important embedded in an image is invisible.

Fix: Every word a recruiter or system needs to read should be selectable text. Open your PDF and try to copy-paste each section. If it doesn't highlight, it doesn't count.

3. Voice-y section headers

"Where I've Been" instead of "Experience." "What I'm Good At" instead of "Skills." Cute, distinct, and parser-hostile. The section detector is looking for a small vocabulary of expected names; anything novel falls through to a generic bucket and your bullets end up unattached to any structure.

Fix: Use the standard names. Save your voice for the bullets themselves.

A 30-second test

Before you ship a resume into the wild, run this:

1. Open the PDF.
2. Select all (Cmd+A or Ctrl+A).
3. Copy.
4. Paste into a plain-text editor — TextEdit, Notepad, anything without formatting.

What you see is roughly what the ATS sees.

If the order is wrong, your columns are confusing the parser. If chunks are missing, those parts were images or unselectable layers. If section headers are gone, your custom labels aren't being recognized.

It isn't a perfect simulation — real parsers are smarter than Cmd-C — but it surfaces around 80% of the issues that quietly tank resumes. Roughly one in three resumes we score inside ResumeFit's analyzer has a parse-level issue the candidate didn't know about.

"Should I use .docx or .pdf?"

There's a piece of folklore that .docx parses better than .pdf. It used to be true. Modern ATS handle both fine now — what matters is how the file was created.

A PDF exported from Google Docs, Word, or Pages will parse well. A PDF exported from Canva or InDesign will often have text trapped inside graphics layers or shapes. A scanned PDF (your resume printed and re-scanned) is almost always unreadable.

Rule of thumb: if you wrote your resume in Word or Docs and exported to PDF, you're fine. If you designed it in Canva or downloaded a template from a graphics-heavy source, run the copy-paste test before you submit anywhere.

The keyword side of the story

The matching half of the parse-and-match pipeline is where the keyword folklore comes from. You've probably heard "use exact keywords from the job description." That advice is correct, but it gets distorted into "stuff every word from the JD into your resume or you won't pass."

Match scores aren't binary. They're weighted sums. Missing the primary skills ("Python," "PostgreSQL," "AWS" for a backend role) drops you steeply. Missing the secondary signals ("agile," "code review," "mentorship") drops you a little. Missing the cargo-cult phrases that aren't real requirements drops you nothing.

If you want a fuller breakdown of how to read a JD and pull the right keywords without sounding like a thesaurus had a stroke, we have a separate post on that.

What changes after you get past the ATS

A clean parse buys you exactly one thing: a recruiter actually opens your resume. From there, the writing, the relevance, and the storytelling carry you. The ATS is a filter, not a judge.

But it's a filter that fails silently on otherwise strong candidates every single day. Spending fifteen minutes on the formatting fixes above is, hour for hour, probably the highest-leverage edit you can make to your job search.

---

If you want a free check on whether your file is parsing cleanly — what the ATS sees, what's missing, what to fix — ResumeFit will tell you in about fifteen seconds. No signup required.

Run a free ATS scan →