Open your resume PDF, select all, copy, and paste it into a plain text editor. That stripped-down version, with no fonts and no layout, is roughly what the parser inside an applicant tracking system sees. If your two-column skills section now reads as “Python TypeScript led a team of React Postgres six engineers,” you’ve found the reason a real resume with real experience gets stored as gibberish.
Most of the panic about ATS software aims at the wrong target. People obsess over keyword density and a secret rejection score, and they ignore the boring mechanical step that comes first: the system has to turn your document into structured fields. Name here, company there, dates over there, skills in a bucket. When that step fails, nothing downstream matters, because the data the recruiter searches and the algorithm ranks is already wrong.
What the software does before anyone reads it
An ATS is a database with a hiring workflow bolted on. Greenhouse, Lever, Workday, iCIMS, Ashby, SuccessFactors, Taleo: they all ingest your file, run it through a resume parser, and store the result as columns in a record. A recruiter later searches that database (“React AND Postgres, San Francisco, 5+ years”) and skims whoever surfaces.
The “75% of resumes are auto-rejected by a robot” line you’ve seen a hundred times is mostly folklore. Very few companies set a hard score cutoff that bins a resume with no human involved, and the ones that do tend to be high-volume retail and call-center pipelines, not engineering roles. What actually sinks technical candidates is quieter. Your title got parsed into the company field. Your most recent job lost its end date, so the system thinks you’ve got a four-year gap. Your skills lived in a sidebar that the parser read straight across, so “Kubernetes” is now glued to your street address. The recruiter searches for the thing you’re great at, and you don’t come up.
The parts that break parsers
Multi-column layouts are the worst offender. A parser reads the text layer of your file in its stored order, which for most designs runs left to right across the full page width, ignoring the visual columns your eye follows. Anything you put side by side gets interleaved. Same story with tables used to line up dates against job titles: the cells can come out in an order that has nothing to do with what you see on screen.
Contact details in the header or footer are a classic miss. A lot of parsers skip the header and footer region entirely, so your email and phone vanish. Text boxes and graphical sidebars get dropped for the same reason. Icons standing in for labels, a little envelope glyph instead of the word “Email,” parse as nothing or as a junk character. Decorative or uncommon fonts can map to the wrong Unicode and turn a clean line into [NULL][NULL][NULL].
Then there’s the file itself. A text-based PDF exported straight from Google Docs or Word is fine, and has been for years; the “never send a PDF” advice is dated. What fails is an image PDF: a scan, a photo, or something exported as a flat picture. There’s no text layer to read, so the parser either returns an empty record or runs OCR and mangles it. If you can highlight individual words in your PDF, it has a real text layer. If selecting grabs the whole page as one block, you’ve got an image.
The keyword game changed, mostly
Old ATS keyword matching was literal. If the posting said “project management” and you wrote “program management,” you missed. That’s much less true now. Workday’s screening layer, Greenhouse’s scoring add-ons, and iCIMS all use language models trained on huge piles of resumes and job descriptions, and they treat “Python development,” “Python programming,” and “wrote Python services” as the same competency. Stuffing exact phrases matters less than it used to.
Two things didn’t change. A recruiter doing a manual boolean search is still matching literal strings, so the actual nouns for your tools need to appear in plain text somewhere. And job title still carries weight, especially in Workday, whose ranking leans hard on whether your past titles map to the seniority of the role. A “Member of Technical Staff” applying for a “Senior Software Engineer” req can score low purely on title distance, even with a perfect skills match. Spelling out the conventional title next to your fancy internal one helps the machine and the human both.
| System | Parsing behavior | What to watch for |
|---|---|---|
| Workday | Handles text PDFs well, struggles with multi-column and embedded tables | Weights job-title match heavily; read the auto-filled fields after upload |
| Greenhouse | More forgiving of modern layouts | Ranking depends on whatever scoring the employer bolts on |
| Lever | Modern parser, reliable on PDFs | Human review tends to happen earlier, so formatting slips hurt less |
| Taleo / older iCIMS | Oldest engines, least tolerant | Stick to single column and standard section names |
How to actually check, not guess
The copy-paste test from the top of this page is the fastest signal and costs nothing. Paste into TextEdit or Notepad and read it as if you were a stranger. Does your work history appear in order? Are your dates attached to the right employer? Did your skills survive as a readable line? If a stretch of it confuses you, it’ll confuse the parser.
The systems will also tell you what they saw, if you let them. When you apply through Workday or Greenhouse, the form usually offers to auto-fill from your upload, then shows you the parsed result before you submit. That preview is ground truth: it’s literally that company’s parser showing its work. If the experience section came out scrambled or a job is missing, fix the document and re-upload before you finish the application. Most people click through this screen without reading it, which wastes the one clear look you get.
A parsing checker is the other option worth using. We built a free in-browser one at /resume-checker/ that shows you the extracted text and flags the usual structural problems without sending your file anywhere. Jobscan does keyword-gap comparison against a specific posting, which helps once your formatting is already clean. There’s also an open-source project, ats-screener, that mimics how several enterprise parsers behave if you want platform-by-platform detail. Any of these beats guessing.
Build it boring on purpose
A resume that parses cleanly is dull to look at, and that’s correct. One column, top to bottom. Section headings that say the obvious words a parser expects: Experience, Education, Skills, Projects. Contact info in the body, not the header. Real text instead of icons. A web-safe font like Arial, Calibri, or Georgia. Dates in a consistent format next to each role. Drop the skills sidebar and put a plain comma-separated line of tools in the body where a boolean search will hit it.
None of this means a flat, keyword-stuffed document. The parser feeds a human, and that human is reading for whether you actually did the work and whether your scope matches the role. Clean formatting makes sure that human gets the real version of your story instead of a scrambled one, and that your name shows up when a recruiter searches for exactly what you can do. The whole check takes five minutes, and you can run it before you send the next application.
Line up the rest of your job search:
