How to Make an ATS-Friendly Resume

Before a human reads your resume, software does. An applicant tracking system (ATS) ingests your file, extracts the text, and maps it into structured fields: name, contact info, work history, skills, dates. If that extraction goes wrong, your experience shows up garbled, misattributed, or missing, and a strong candidate looks weak on screen.

Most "ATS-optimized" advice obsesses over keywords. Keywords matter, but the more common failure is mechanical: the parser cannot read the file cleanly in the first place. No tool can guarantee you pass every ATS on the market, since they vary in quality. What you can do is remove the formatting failure modes that cause parsers to choke. That is the part fully under your control, and it is where most resumes lose points before anyone evaluates the content.

What an ATS actually is

An ATS is the system recruiters use to receive, store, and filter applications. When you upload a PDF or DOCX, the system runs it through a parser that tries to reconstruct structured data from your document. Some systems then score or rank candidates against the job description; others just store the parsed fields so a recruiter can search them later.

The key insight: the ATS does not "see" your resume the way you do. It does not see a layout. It sees a stream of extracted text plus whatever positional and structural hints it can recover from the file. Your job is to make that extraction unambiguous.

How parsing works

Parsing happens in roughly two stages.

1. Text extraction. The parser pulls the raw text out of the file. For a real text-based PDF, this means reading the embedded text objects and their Unicode mappings. For an image-based PDF (a scan, or a design exported as a picture), there is no text to read, so the system either runs OCR (error-prone) or gives up.
2. Field mapping. The parser segments the extracted text into sections and fields. It looks for section headers ("Experience," "Education," "Skills"), date patterns, and reading order to decide what belongs where.

Both stages break when the file fights the parser. If the text is not really text, stage one fails. If the visual layout does not match the underlying reading order, stage two fails. This is the difference between a resume that looks fine to you and one that parses cleanly.

Common mistakes that break parsing

These are the formatting choices that reliably cause trouble:

• Tables used for layout. Designers love tables to align columns. Parsers read table cells in an order that often has nothing to do with how you intended the content to flow. Your job title can end up attached to the wrong company.
• Multi-column layouts. A two-column resume looks modern, but many parsers read straight across the page, interleaving your sidebar (skills, contact info) with your main column (experience). The result is scrambled text.
• Text inside images. A name rendered as a logo, a skills chart exported as a graphic, an "infographic" resume. There is no extractable text behind a picture, so that content is invisible unless OCR happens to catch it.
• Headers and footers. Some parsers ignore the header/footer regions of a document entirely. Put your phone number or email up there and it can vanish.
• Fancy or non-standard fonts. Decorative fonts, or fonts embedded without proper Unicode mappings, can cause character substitution. Your "fi" ligature, your accented characters, your bullet glyphs come out as garbage or empty boxes.
• Glyph-based icons. Those little icon fonts for email and phone often map to private-use Unicode code points that extract as junk characters wedged against your real contact details.
• Special characters and smart punctuation. Curly quotes, en/en symbols, and exotic bullets can survive or corrupt depending on the encoding.

Notice that none of these are about content. They are about whether the parser can recover your content at all.

Why a text-based, tagged PDF parses cleanly

A PDF is not a single thing. There is a large gap between a PDF that contains real text and one that is just a picture of text.

A well-built text-based PDF carries:

• Selectable, embedded text. Every word is a real text object. If you can select it with your cursor and copy it into a notepad without losing anything, a parser can read it too.
• Correct Unicode mappings. Each glyph maps back to the right character, so accented names, technical symbols, and punctuation extract accurately instead of turning into boxes.
• Tags and a defined reading order. A tagged PDF (the structure behind PDF/A, the archival PDF standard) encodes the logical reading order and document structure. This is exactly the hint stage-two field mapping needs to keep your job titles attached to the right employers.

RenderCV generates resumes through Typst, a modern typesetting engine that outputs text-based, tagged PDFs with a clean reading order and correct Unicode. There is no image layer, no layout-table trickery, and no glyph soup. The text you see is the text the parser extracts. That does not magically defeat a badly written ATS, but it removes the entire class of extraction failures described above.

This is not a claim made loosely. RenderCV tested it empirically: 4 resumes rendered across all 5 themes (20 PDFs total), each run through two independent text extractors and three commercial resume parsers (Affinda, Extracta, and Klippa, the same engines real ATS platforms rely on). Every single PDF parsed correctly, with names, emails, phone numbers, companies, job titles, dates, and degrees extracted intact, at 99% text-extraction accuracy across every theme. The full methodology and results are published in the RenderCV ATS Compatibility Report.

Contrast that with the typical "designer template" PDF: a two-column layout built on tables, contact info in the header, icon fonts for the social links, and sometimes the whole thing flattened to an image on export. Every one of those is a parsing landmine.

A clean RenderCV example

Single column, real section headers, plain-text skills grouped by category, contact details in the body rather than a header. This is the structure parsers handle without complaint:

cv:
  name: Jordan Lee
  location: Austin, TX
  email: jordan.lee@email.com
  phone: "+15125550199"
  website: https://jordanlee.dev
  social_networks:
    - network: LinkedIn
      username: jordanlee
    - network: GitHub
      username: jordan-lee

  sections:
    summary:
      - Software engineer with 5 years of experience building
        backend services and data pipelines. Focused on
        reliability and measurable performance gains.

    experience:
      - company: Cloudflare
        position: Software Engineer
        location: Austin, TX
        start_date: 2021-07
        end_date: present
        highlights:
          - Built an event-driven ingestion pipeline in Go
            processing 3M events/day, cutting median latency
            by 35%.
          - Migrated CI from Jenkins to GitHub Actions across
            9 repositories, reducing build time by 50%.

    education:
      - institution: University of Texas at Austin
        area: Computer Science
        degree: BS
        start_date: 2015-09
        end_date: 2019-05

    skills:
      - label: Languages
        details: Go, Python, TypeScript, SQL
      - label: Infrastructure
        details: Kubernetes, Docker, Terraform, AWS

design:
  theme: engineeringresumes

The engineeringresumes theme is single-column by design. Every date is parsed and formatted consistently, every section has a clear header, and the output is a text-based PDF the parser reads top to bottom. For a fuller version, see the software engineer resume example.

The do / don't checklist

Do:

• Use a single-column layout with one logical reading order.
• Use standard, explicit section headers: Experience, Education, Skills, Projects, Summary.
• Keep contact information in the body of the document, not in the page header or footer.
• Use real, selectable text with a standard, well-embedded font.
• Write dates in a consistent format and put them inline with each entry.
• Export a text-based PDF, then confirm you can select and copy the text cleanly.
• Save a master plain-text data file (such as YAML) so your content is portable and reusable.

Don't:

• Don't build layout with tables or split your resume into columns.
• Don't put text inside images, logos, charts, or "infographic" elements.
• Don't rely on icon fonts for contact details or section markers.
• Don't bury contact info in headers or footers.
• Don't use decorative fonts or unusual special characters in critical fields.
• Don't submit a scanned or image-exported PDF.

A fast sanity check for any resume PDF: open it, select all, copy, and paste into a plain-text editor. If the result is in the right order and nothing is missing or mangled, a parser will likely read it the same way. If it comes out scrambled or empty, fix the file before you fix the wording.

Where formatting ends and content begins

Clean parsing gets your content into the system intact. After that, the usual advice applies: mirror the language of the job description, lead bullets with measurable impact, and group skills the way the posting does. RenderCV's bold_keywords setting lets you emphasize a tech stack for human readers while the parser still sees clean text underneath.

If you are still deciding what document you even need, the distinction between a CV and a resume matters, and if you are in tech, knowing how to put GitHub on a resume without breaking the parse is worth getting right.

The broader idea is treating your resume like any other artifact you maintain: a plain-text source of truth, a reproducible build, and an output you can inspect. That is the resume as code approach, and it happens to produce exactly the kind of file ATS parsers handle best.

You cannot control which ATS a company runs or how well it was built. You can control whether your file hands that parser clean, ordered, real text. Start with a tool that does that by default.

Build an ATS-friendly resume at rendercv.com