Most advice about applicant tracking systems is a decade out of date or plain invented. The famous claim that 75% of resumes are rejected before a human sees them traces back to one 2012 experiment with a single fake resume. Modern ATS software parses clean resumes reliably. What it can't do is rank you for keywords you never wrote, and that's where applications actually die.
When you apply, the system converts your file into structured data: name here, jobs there, dates parsed, skills extracted. A recruiter then searches or scrolls a ranked list, usually by keyword, usually within the first few days of a posting going live. So two things matter: the parse has to be clean, and the content has to match the posting's vocabulary. Formatting failures happen, but they're rare with a normal document. Keyword misses happen constantly, and they're invisible to you.
Roughly in order of how often they cause real problems:
Notice what's missing: no white-text keyword stuffing (systems detect contrast now, and recruiters see it when they open the file), no paying for an "ATS-certified" template (that certification doesn't exist), no keeping the resume ugly on purpose. A clean single-column document with real headers is all the compliance you need.
Read the posting and pull out every repeated noun. Tools (Salesforce, Figma, PostgreSQL), methods (Agile, reconciliation, A/B testing), credentials (PMP, CPA, BLS). Then use those exact words where they're true for you. Write "search engine optimization (SEO)" on first use so both forms exist in the document. This isn't stuffing; it's translation. You've been calling it "demand gen" and the posting says "demand generation" — the system doesn't know those are the same.
| You wrote | Posting said | Result |
|---|---|---|
| "Ran the company blog" | "Content marketing and SEO" | No match |
| "Owned content marketing and SEO for the company blog, growing organic traffic 62%" | "Content marketing and SEO" | Match + evidence |
Put the critical ones in three places: the summary sentence, the bullet points of the relevant job, and the skills section. A keyword that appears only in a skills list looks thin to both the ranking algorithm and the human reviewing the shortlist. One that shows up inside an achievement reads as proof.
Single-column templates, standard headers, live preview, and PDF export that parses cleanly.
Open the Resume Builder →Three checks, five minutes total. Copy-paste your PDF into a plain text editor: if the text arrives in reading order with nothing scrambled, parsers will be fine. Search your own document for the posting's top five keywords: all five should appear. And run a word count with our word counter: a one-page resume lands around 400–600 words, and if you're at 900, the problem isn't the ATS, it's the editing.
The same document has to survive a 7-second skim. Clear headers, bolded job titles, bullets that start with verbs and end with numbers. The overlap is convenient: everything that parses well also skims well. Once the resume is solid, a three-paragraph letter that names the company and leads with your best number closes the loop — our cover letter generator handles the structure while you supply the specifics.
The widely repeated 75% figure traces to a 2012 pre-screen of a single fake resume, not a study of real pipelines. What actually happens: modern systems parse most resumes fine and rank them against the posting. You get filtered when your keywords don't match, not because a table confused the parser. Write for the reader, match the vocabulary, and you clear the software.
Either, with one caveat. Modern ATS platforms parse text-based PDFs well. If a posting or recruiter explicitly asks for .docx, send .docx. Never send a scanned image or an exported design-tool PDF with text as outlines; those parse as blank pages.
Read the posting and note every repeated noun: tools, methods, certifications, regulations. Use the posting's exact phrasing, including abbreviations paired with the long form the first time (SEO/search engine optimization), because you can't know which variant the system indexes.
Tables and two-column layouts are the riskiest common choice: some parsers read them out of order. Icons, skill bars, and headshots usually drop out entirely. A single-column layout with plain section headers eliminates the whole class of problems, and no recruiter has ever complained about one.