Build a Resume That Applicant Tracking Systems Can Actually Read

An applicant tracking system is a database with a form on the front. When you upload a resume, the system does not "read" it the way a person does. It first converts the file to plain text (for PDFs this means extracting the text layer; for DOCX it walks the XML), then runs a parser that tries to segment that text into structured fields: contact details, a list of employers with titles and date ranges, an education block, and a skills list. Those fields are what recruiters search, sort, and filter on.

This is why formatting matters more than it seems. The parser has no idea that a two-column layout is meant to be read left column first. It receives the text in whatever order the PDF's internal structure emits it (frequently interleaving lines from both columns) and then tries to guess where one job ends and the next begins. A resume that looks polished to a human can arrive in the recruiter's search index as a scrambled block with no dates attached to any employer.

Major ATS vendors (Workday, Greenhouse, Lever, iCIMS, SAP SuccessFactors, Taleo, SmartRecruiters) each use their own parsing stack, and some license third-party parsers. Their exact behaviour differs, but they share the same failure modes because they are all trying to solve the same problem: turning a free-form document into fielded data.

Most parse failures come from a short list of causes. Multi-column layouts are the most common. Tables used for alignment are the second: many parsers drop or flatten table cells. Text rendered inside images, icons used in place of section labels, and headers or footers that contain contact details are all routinely lost, because parsers often skip header/footer regions entirely.

Section headings matter too. Parsers look for recognisable labels ("Experience", "Work Experience", "Professional Experience", "Education", "Skills") to decide which field a block belongs to. Creative headings like "My Journey" or "Toolbox" can leave a block unclassified. Date formats that mix styles ("Jan 2022 – present" in one entry, "2023-03" in another) make it harder to compute tenure, which some systems use as a filter.

• Use one column, top to bottom, with no text boxes or sidebars.
• Keep contact details in the body, not the header or footer.
• Use standard section labels: Experience, Education, Skills, Certifications.
• Use real text for everything: no skills rendered as icons or bar charts.
• Use a consistent date format for every role (e.g. "Mar 2022 – Present").
• Save as PDF with a text layer, or DOCX; never export a resume as an image.

Recruiters configure searches and knock-out questions using the vocabulary of the job posting. If the posting says "Kubernetes" and your resume says "container orchestration", a literal keyword search misses you, even though a human would connect the two. The fix is not to paste the posting into your resume; it is to describe the work you genuinely did using the same nouns the posting uses, where those nouns are accurate.

Ravina's keyword analysis compares the posting's explicit skills and tools against your resume text and shows what is missing. It deliberately does not produce a single "match percentage": those scores imply a precision that no external tool can have, because no one outside the company knows what the recruiter actually searched for. What it can tell you reliably is which named terms from the posting do not appear anywhere in your document.

Every one of the structural problems above is detectable with rules: count columns, detect tables, look for text in images, check heading labels against a list, validate date patterns, look for numbers in bullets. Running these as deterministic checks means the result is the same every time, it works offline, and it costs nothing. Ravina reserves AI for the part that benefits from it (rewriting a bullet to be clearer and more specific) and uses your own provider key for that, so there is no per-scan quota to protect.

The checks fall into four groups: layout (column structure, tables, text that only exists inside images), tokenisation (date formats, section heading hierarchy, contact details the parser can find), text-layer readability of the exported file, and bullet quality (quantified results, action verbs, and a filter for machine-generated buzzwords). The free version on this site runs the bullet-quality subset in your browser; the full set runs inside Ravina.