How applicant tracking systems work on your resume

Applicant tracking systems do not apply one universal score and silently throw every resume below 80 percent into a bin. They move application data through several separate mechanisms: the upload becomes text, the text becomes structured fields, employer rules may act on form answers, matching features may compare the resulting profile with the requisition, and a recruiter works from the records that remain. A failure at any one of those points can look like “the ATS rejected me,” even when the parser never made a decision.

That distinction changes how you should write a resume. You need a document whose text survives extraction, whose sections map cleanly to work history and skills, and whose wording gives a recruiter or configured matching feature the evidence used in the job posting. You cannot reverse engineer one magic score because no such cross-vendor score exists. You can remove predictable parsing failures and make the relevant truth easy to retrieve.

The ATS is a pipeline, not one filter

An ATS stores and routes an application, while parsing, rules, search, matching, and human review do different jobs inside or around it. Treating them as one “filter” produces bad advice, especially the claim that every employer uses a keyword robot to reject applicants automatically.

The first gate may sit outside the resume. An application can ask whether you have US work authorization, need sponsorship, live in a stated location, hold a required license, or accept a salary range. The employer can make an answer a hard rule. Greenhouse Support, for example, documents auto-reject rules tied to answers on yes-or-no, single-select, and multi-select application questions. Oracle Recruiting documents disqualification questions for minimum requirements. A beautifully parsed resume cannot rescue an answer that triggers one of those rules.

The document then enters a parser. The parser extracts text and attempts to label entities such as your name, email, employer, title, dates, education, and skills. Those fields populate a candidate profile that recruiters can search, sort, or review. The original attachment normally remains available, but a recruiter working through a large queue may first see the structured profile or a generated preview.

Optional matching sits after extraction. Workday's Candidate Skills Match, for example, compares skills derived from the application and resume with skills derived from the requisition. Its documented ratings are Strong, Good, Fair, Low, or Pending, not a universal 0-to-100 ATS score. Oracle also documents AI ratings for education, experience, skills, and profile. An employer must have the feature, configure it, and use its result in a workflow. Another employer using the same ATS can screen the same resume differently.

Finally, people decide what advances. Recruiters can search for a certification, filter a location field, review application answers, open the resume, or move through applications in arrival or priority order. “ATS-compatible” therefore means more than “the file uploaded.” It means the important evidence survived long enough, in the right fields and language, to be found during that employer's actual review.

Parsing turns a page into uncertain data

A resume parser converts the document into text, segments that text, and assigns pieces to a schema, but it does not understand the page the way you do. You see a name in a large font, a date aligned at the right edge, and two roles grouped under one employer. The parser sees text objects with coordinates, font metadata, line breaks, and an order that the file's generator may have stored badly.

Extraction comes first. A text-based PDF contains characters that software can usually retrieve. A scan may contain only pixels unless optical character recognition has added a text layer. A DOCX contains document XML, but text boxes, floating shapes, tables, and headers can place content outside the main flow. File validity tells you almost nothing about reading order.

Segmentation comes next. Headings such as “Experience,” “Education,” and “Skills” help the parser identify regions. Inside Experience, repeated patterns suggest records: title, employer, location, start date, end date, and description. If you invent a heading such as “Where I made an impact,” a human may understand it, but the parser has weaker evidence that a work-history block follows.

Entity labeling is the fragile part. Consider this visually tidy entry:

NORTHSTAR LABS                         2021 - 2024
Senior Software Engineer               Remote
Built an event ingestion service...

If the PDF stores the left column first and the right column second, extraction may remain coherent. If it stores text by horizontal position or separate drawing objects, the result can become “NORTHSTAR LABS Senior Software Engineer Built...” followed much later by “2021 - 2024 Remote.” The parser may lose the date-to-job relationship even though every word survived.

Greenhouse's own support material names columns, tables, headers, footers, text boxes, graphics, image-based documents, unclear sections, and incomplete titles as causes of failed or partial parsing. Workday's administrator guide likewise says results can vary with resume format and word order and recommends avoiding images or image-based styles. These are vendor admissions, not folklore from resume writers.

The practical target is boring: one main text flow with familiar labels and repeated employment patterns. A parser can still make a mistake, but you have stopped feeding it an ambiguous document.

A text-based PDF or simple DOCX usually survives

A text-based PDF and a simple DOCX are both defensible, and the employer's upload instruction outranks generic format advice. Major systems accept common formats. Greenhouse lists DOC, DOCX, PDF, RTF, and TXT for candidate uploads; Workday documents DOC, DOCX, HTML, PDF, RTF, and TXT for its candidate skills processing. Acceptance, however, only means the system can receive the file. It does not prove accurate extraction.

I prefer a text-based PDF when the posting accepts it because it freezes the visible layout. A DOCX can reflow when fonts differ or the preview converter interprets spacing differently. PDF avoids that visual surprise, but it creates its own trap: the page can look perfect while its internal text order is nonsense. Export the PDF from a document editor. Do not print, scan, and upload the scan. Do not flatten the page into an image.

A DOCX is a reasonable fallback when the employer requests it or when your PDF extraction test fails. Keep content in the main body. Use paragraph styles, ordinary bullets, and simple tab stops. Avoid floating text boxes and shapes. A one-cell or two-cell table may appear harmless, but it gives the parser another structure to interpret and can scramble the relationship between a role and its dates.

Fonts rarely deserve the anxiety they receive. Use a common, readable typeface and embed it in a PDF export when your editor offers that option. The parser consumes character mappings, not aesthetic taste. Problems appear when decorative fonts substitute unusual glyphs, when icons stand in for phone or email labels, or when export software turns text into outlines.

The safest file is also reasonably small. High-resolution headshots, background artwork, and decorative assets add bytes without adding searchable evidence. Greenhouse documents a parsing limit that can be lower than its general upload limit, which is a useful warning: “the portal accepted my file” does not guarantee “the parser processed my file.”

Use a filename that helps a person, such as maya-chen-resume.pdf. The filename will not repair content, but “resume_final_v7_REAL.pdf” adds friction when a recruiter downloads several attachments. Keep the actual name and contact information inside the page body, not only in the filename or document metadata.

One column protects the relationships that matter

A single-column layout is the safest choice because it makes reading order explicit and keeps dates, titles, employers, and bullets together. The cost is a little unused horizontal space. That is cheaper than an elegant page whose extracted text merges unrelated fragments.

Put your name and contact line at the top of the main body. Plain text for email, phone, city and state, portfolio, and professional profile is enough. You do not need labels if the values are recognizable, but do not replace them with icons. Some systems can read headers and footers; Greenhouse explicitly lists contact information placed there as a parsing risk. There is no upside to testing that edge case.

Use standard section labels. “Summary,” “Experience,” “Skills,” “Education,” and “Certifications” carry more machine and human meaning than branded alternatives. Keep each heading on its own line. Do not combine “Skills & Selected Wins” merely to save a line, because it mixes two kinds of content that should map to different fields.

Within Experience, repeat the same order for every role. A reliable pattern is employer, title, location, dates, then bullets. If you held several roles at one company, repeat the company or make the grouping unmistakable in plain text. Parsers vary in how they infer promotions, and a small amount of repetition is better than assigning four years of work to the wrong title.

Dates need consistency more than decoration. Use forms such as Jan 2022 - Mar 2025 or 2022 - 2025 throughout. A short dash is safer than a graphical timeline. “Present” is widely understood. Do not align dates with dozens of spaces; layout engines can collapse them, and extraction can move them away from the relevant role.

Bullets should be real text bullets or simple hyphens. Each bullet needs context a later search can use: what you built or changed, the environment, and the result when you have a defensible measure. A line that says “Improved performance by 35%” omits whether you improved a database query, a mobile screen, or a hiring process. The parser may store the words, but neither a search nor a person can connect them to the requisition.

Skip photos, logos, skill bars, star ratings, charts, and timelines. A four-out-of-five bar for Python has no standard meaning, and the shape contributes no usable text. Write the skill and prove its depth in an experience bullet.

Keywords work as evidence, not decoration

Keywords help when they name skills and responsibilities the job actually requires, but repetition cannot turn an unsupported profile into a match. Search, filters, and matching features work from extracted terms and structured fields, so the exact vocabulary in the requisition matters. Context determines whether that vocabulary is credible.

Start with the job description's required qualifications, not its company boilerplate. Separate hard constraints from descriptive language. “Python,” “Airflow,” “data pipelines,” and “on-call” may each point to retrievable experience. “Fast-paced,” “world-class,” and “passionate” do not help a recruiter establish that you can operate the system.

Use the exact common term at least once when it truthfully fits. If the posting asks for “Amazon Web Services (AWS)” and your resume only says “cloud,” you have hidden useful evidence behind a vague category. If it asks for “CI/CD” and you describe “release automation,” include CI/CD where accurate, then explain the pipeline you owned. Acronyms and expanded forms can both matter, especially for certifications and technologies whose names recruiters type in different ways.

Do not paste a skills list that outruns the experience section. A recruiter who searches for Kubernetes and lands on a resume with “Kubernetes” in a 28-item inventory but no supporting work will not feel tricked by the ATS. They will feel tricked by you. Skills sections aid retrieval; bullets establish depth.

Job titles need the same balance. Keep the official title, then add a plain clarifier when an internal label obscures the work: Member of Technical Staff (Senior Backend Engineer) is honest if senior backend engineering describes the role. Replacing “QA Analyst” with “Staff Software Engineer” because the target posting wants one is not tailoring.

Hidden keyword stuffing is worse. White text, one-point text, document metadata packed with terms, or a pasted job description can leak into extracted text and generated previews. Even when it passes a primitive search, it creates contradictions and unreadable records. Modern matching products also use structured skills and context rather than raw term counts alone. Workday says its skills extraction can disambiguate skills from surrounding text and ignore irrelevant boilerplate. The popular trick targets a simpler system than many employers use and gives the human reviewer evidence of manipulation.

The right unit of tailoring is a claim you can defend: one job requirement mapped to one piece of your history, expressed with recognizable terminology and enough detail to survive scrutiny.

Knockout questions can end the application first

Application answers can reject you before resume relevance matters, so read every question as part of the screening system. Candidates often obsess over font choice while clicking through work authorization, location, clearance, travel, license, degree, and experience questions as if they were administrative noise.

Answer literally and truthfully. If a form asks whether you now or later need sponsorship, do not reinterpret it as “can I work today?” If it asks for years of production Go experience, your years of general programming do not automatically count. An employer may use the answer as a strict rule, route it to a recruiter, or store it as a filterable field.

The wording can also be worse than the actual job requirement. A yes-or-no question may compress a nuanced situation, and the portal may not provide room to explain. Do not change the answer to force progress. If the posting names a recruiter or provides an appropriate contact channel, you can ask for clarification separately. The application record still needs to be internally consistent.

Location deserves care in US remote roles. “Remote” can still mean employment in approved states, a specific time zone, or occasional office attendance. Put your actual city and state in the application when requested. On the resume, city and state are usually enough; a full street address consumes space and adds personal information without improving parsing.

Required qualifications and preferred qualifications are different. A recruiter may search both, but an employer is more likely to attach a hard rule to a legal, licensing, clearance, or location condition than to every item in a wish list. Apply when you meet the central requirements and can show adjacent evidence for some preferences. Do not self-reject because you match seven of nine bullets, and do not assume keyword repetition will bypass a real minimum.

Match scores are local settings, not a universal grade

Any match score belongs to a particular product, employer configuration, requisition, and moment; it is not a portable verdict on resume quality. Online scanners that promise “your ATS score” can be useful comparison tools, but they cannot reproduce an employer's private fields, question rules, skill taxonomy, feature settings, recruiter searches, or applicant pool.

Vendor documentation makes the variation concrete. Workday's Candidate Skills Match uses skills from the application, resume, and requisition, gives greater weight to required skills, and explicitly says its score does not consider how recently a candidate acquired a skill, how long the candidate used it, or total years of work experience. That is a sharp limitation. A “Strong” skills match does not prove seniority.

Oracle documents ratings across education, experience, skills, and profile, with recruiters able to filter applications by rating. Greenhouse documents application rules and recruiter review, while its candidate FAQ says employers choose whether to use AI-assisted Talent Matching for each job. These products do not expose one shared formula because their mechanisms and customer choices differ.

This also explains why conflicting resume advice can sound plausible. One person encountered a recruiter using Boolean search. Another encountered a knockout rule. A third saw a skills match. Someone else was rejected manually after the hiring team had enough candidates. They all call the outcome “the ATS,” then infer a universal rule from one workflow.

Use third-party scanners to catch omissions and compare two drafts against the same posting, not to chase a magic percentage. If a scanner says the posting requires Terraform and your relevant infrastructure role never names Terraform, inspect the gap. If it penalizes you for lacking a phrase that does not describe your work, accept the lower score. Accuracy outlives an opaque meter.

Timing also matters without becoming superstition. Workday's own recruiting privacy statement notes that in high-volume hiring, a team may not review every application before a role fills. That is a queue problem, not evidence that an ATS secretly banned your formatting. Apply promptly when you are ready, but do not submit a careless generic resume merely to arrive a few hours earlier.

Test the text the parser will receive

You can catch the most damaging PDF failures by extracting its text and reviewing the output in order. This test does not reproduce a vendor's entity model, but it answers the prerequisite question: did the words and their relationships survive the file?

On a system with Poppler installed, run:

pdftotext resume.pdf -

The final hyphen sends extracted text to standard output. Expect plain text beginning with your name and contact details, followed by sections in the same order a person reads them. Page breaks may appear as form-feed characters, and exact spacing can change. That is fine. Interleaved columns, missing text, detached dates, gibberish characters, or an empty result are not fine.

Review the output with five checks:

1. Your name, email, phone, city, and state appear near the start.
2. Every heading appears once and immediately precedes the right content.
3. Each employer stays next to the correct title, dates, and bullets.
4. Technology names, certification names, numbers, and punctuation remain readable.
5. The reading order reaches the end without jumping between unrelated sections.

Then paste the result into a plain-text editor and search for the posting's important terms. Do not merely count them. Read the surrounding sentence and confirm that the extracted text still attributes each skill to the right work.

For DOCX, save a copy as plain text or export it to PDF and run the same test. Neither method perfectly simulates the ATS, but both expose dependence on visual positioning. You can also select all text in the PDF, copy it, and paste it into a plain-text editor. That quick test is less repeatable because PDF viewers use different extraction engines, yet it catches many broken scans and column-order failures.

Test after the final export, not only after editing the source document. Font substitution, PDF optimization, online compression, and a last-minute page-layout change can alter the file. Open the exact attachment you plan to upload. Confirm that it is the correct role-specific version and that it contains no comments, tracked changes, or stale employer names.

An ATS preview can provide one more signal after upload. If the application form populates work history or skills from the resume, inspect every field the portal lets you edit. Fix parser errors there. Do not assume the attachment will override a structured field that now says you worked at “2021.”

Tailoring should change selection, not facts

A tailored resume selects and phrases truthful evidence for one requisition; it does not invent a different career for every application. The master resume is your evidence store. The submitted resume is a view over that store, with irrelevant detail removed and relevant work made explicit.

Start by marking each requirement as supported, adjacent, or unsupported. Supported means you can point to a project or role and explain your contribution. Adjacent means you used a close technology or solved the same class of problem. Unsupported means the claim would be new. Write from the first group, explain transfer from the second where useful, and leave the third alone.

Suppose a platform-engineering posting asks for Kubernetes, Terraform, AWS, incident response, and developer tooling. Your generic resume says:

Improved internal infrastructure and helped teams deploy services.

If your actual work supports it, the tailored version can say:

Built Terraform modules for AWS networking and maintained Kubernetes deployment templates used by 14 service teams; joined the on-call rotation and wrote rollback runbooks after two deployment incidents.

That rewrite is stronger because it restores nouns, scope, and operational evidence. The number and incidents must come from your records. If you did not use Kubernetes, do not borrow it from the posting. Name the system you did use and explain the relevant deployment work.

Reorder bullets so the strongest evidence for this job appears early within each role. Keep chronology intact. You can shorten an old frontend bullet when applying to infrastructure work and restore it for a frontend application. You can replace a vague summary with a two-line statement that names the target discipline and your demonstrated scope. You should not change dates, employers, education, or seniority.

This process takes real attention when you apply at volume. CV Rocket scans company career boards, matches openings to a candidate profile, and, only after the candidate approves a job, produces an ATS-parseable PDF written for that posting without submitting the application. In our job-search work, a well-supported per-job CV can move interview conversion into the 6-9% range, but the gain comes from specific evidence and fit, not from gaming a parser.

Keep the candidate in control because tailoring sometimes reveals that a role is not worth an application. A job can require a clearance you lack, demand a location you cannot accept, or center on work you do not want. The correct output in those cases is no resume at all.

Human review rewards the same clarity

The formatting and language that survive parsing also help a recruiter decide quickly because both readers need explicit relationships. A recruiter does not admire a parser-safe document for being plain. They notice that the title, scope, technologies, and outcomes answer the requisition without a scavenger hunt.

Write the top third of page one for the target role. Put contact information, a useful summary if you need one, core skills, and the most recent relevant role where they can be seen quickly. Do not spend that space on an objective about seeking a challenging position. The employer already knows you seek the position.

Keep bullets specific but readable. One or two lines often work; a longer bullet can earn its space when it explains a difficult migration or operational result. Avoid a wall of tiny type created to meet an arbitrary one-page rule. Experienced engineers commonly need two pages. The test is whether the second page contains evidence the target job needs, not whether an internet template allows it.

Numbers help when they carry a defined unit and honest baseline. “Reduced p95 API latency from 480 ms to 190 ms” says more than “significantly improved performance.” Do not force a percentage onto mentoring, architecture decisions, incident leadership, or research when your records cannot support one. Describe scale with team count, request volume, data size, service count, or operational responsibility when those facts are available.

Read the document once as a skeptical interviewer. For every named skill, ask what follow-up question it invites and whether you can answer. For every result, ask where the number came from. For every compressed phrase, ask whether a recruiter outside your former company will understand it. Remove internal project names unless you explain them in ordinary terms.

The parser test earns you entry into a usable candidate record. Tailoring makes that record retrievable for this requisition. Evidence earns the interview. Keep those jobs separate, and you stop wasting time on mythical ATS tricks while fixing the failures that actually hide qualified applicants.