Why your resume keeps getting filtered by ATS (and what actually fixes it)
Most rejections are not the recruiter saying no. The recruiter never saw the resume. An applicant tracking system parsed the file, failed to extract some field it needs, and dropped the application into a queue that does not get reviewed.
We instrumented the parsers used by Lever, Greenhouse, Workday, iCIMS, and Taleo against a sample of 4,000 resumes uploaded to Offersly. Same content, different formats. Then we measured which formats reached the recruiter and which did not. Here is what failed, what worked, and the five fixes that move the needle.
What the parser actually sees
An ATS does not "read" your resume. It extracts text spans and maps them to named fields: full name, email, phone, current title, current employer, education, total years of experience, skills. If a span does not map cleanly, the parser leaves the field blank and the candidate scores zero on the recruiter's filter for that field, even when the information is right there on the page.
The mapping is brittle. Tables confuse it. Multi-column layouts with floated sidebars confuse it. PDFs exported as flattened images confuse it utterly. Custom fonts that ship glyphs at non-standard Unicode codepoints confuse it.
The five failures we saw most
1. The sidebar that ate the skills section
Multi-column templates with the skills list in a left or right sidebar reach the parser as one continuous stream. The parser reads top to bottom of column A, then top to bottom of column B. Your "Skills: Python, SQL, React" string gets glued to the end of an unrelated section header from column A. Field extraction misses it.
2. Flattened-image PDFs
Designed in Figma, exported as PNG, embedded in a PDF wrapper. Looks crisp. Parses as zero text. The parser sees a single opaque image and returns nothing extractable. Every named field is blank. The application sits in the unranked pile.
3. Tables for layout
Tables that hold rows of (Date | Title | Employer) data parse unpredictably across ATS engines. Some flatten row-by-row, some column-by-column. Word's "two-column layout" is often a hidden table — same problem.
4. Custom fonts with PUA codepoints
A handful of premium icon fonts encode their glyphs in the Unicode Private Use Area. Visually you see a clean phone icon next to your number. The parser sees U+F095, drops it, and the surrounding spacing collapses your phone number into the next field.
5. Headers and footers
Word's header/footer regions are a separate layout layer. Some parsers ignore them entirely. Your name lives in the header for visual elegance; the parser cannot find a name; the recruiter filter that requires Name is non-empty drops you.
What actually works
- Single-column layout, native text PDF. Boring. Parses correctly across every ATS we tested.
- Standard system or web fonts. Inter, Arial, Times New Roman, Helvetica, Calibri. Skip the icon fonts.
- Name + contact at the top of the body, not the header. Make sure copy-pasting the PDF reveals your name on the first line.
- One section per heading. Experience. Education. Skills. Certifications. Use these exact words. Custom section names like "My Journey" cost you the field map.
- Dates in a consistent format. "Mar 2023 – Present" parses reliably. "March 2023 - Now" sometimes drops.
How to verify before you submit
The cheapest verification: open your PDF in any reader, hit Ctrl/Cmd-A, then Ctrl/Cmd-C, then paste into a plain text editor. If the resulting text is in the order a parser would read it, with no garbled icon characters, your file will reach the recruiter. If it is missing your name, jumbled across columns, or full of question marks, fix it before submitting.
Run that test before you spend a week applying. It takes 30 seconds and predicts your reach better than any "ATS score checker" we have seen.