How to Make Your Resume Machine-Readable

Your resume has two readers now. One is a tired human who skims for eight seconds. The other is software. It opens your file, hunts for fields it recognizes, and turns your career into rows in a database. If the software trips, the human may never see you at all.

So machine-readability is not a nice-to-have. It is the gate before the gate. And most resumes were designed for the eyes, not the parser, which is why so many good candidates quietly vanish into a queue nobody reviews.

A machine-readable resume is career data structured so software can parse it reliably, using real selectable text, predictable section names, and ideally a stable URL where an AI recruiter or ATS can fetch it on demand.

This guide walks the whole ladder. It starts with the boring fundamentals that fix 90 percent of parsing pain, then climbs to structured data and a published cv.json file, which is where hiring is heading. Every step is something you can do today, free.

Step 1: Use real text, not pictures of text

The single most common way a resume breaks a parser is also the most invisible. The file looks perfect to you. To the software it is a wall of pixels.

This happens when a resume is exported as a flat image, scanned from paper, or built in a design tool that rasterizes text. The words are there. They just are not selectable. A parser reaching for your job title finds nothing, because there is no title to find, only a shape that looks like one.

The two-second test

Open your PDF. Try to highlight your name with the cursor and copy it. Paste it into a notes app. If your name appears as text, the parser can read it. If you cannot select it, or it pastes as gibberish, you have an image, and you need to rebuild the file from a source that exports real text.

Same logic applies to logos, icons, and those little skill-rating dots. A parser cannot read "expert" from four filled circles and one empty one. It reads four shapes and moves on. If a fact matters, write it as a word.

If you cannot highlight and copy a piece of text in your resume, neither can the software deciding whether to forward you.

About fonts and embedding

Use a common font: Arial, Calibri, Georgia, Helvetica, something a parser has met before. Decorative fonts can map to the wrong characters during extraction, so your carefully typed "Engineer" arrives as "Eng neer" with a missing glyph. When you export to PDF, embed the fonts. Most export dialogs do this by default, but check, because a non-embedded font shifts the burden of guessing onto the reader's machine.

Step 2: Use standard section names

Parsers work by pattern. They scan for headings they recognize, then grab the text underneath and file it. Give them headings they know and the whole document falls into place.

So name your sections plainly. Work Experience or Experience. Education. Skills. Certifications. Projects. These are the labels parsing engines were built around, and they map cleanly to the fields an ATS stores.

Clever headings cost you. "Where I've Made Impact" reads beautifully to a recruiter and reads as nothing to a parser, which has no rule for it and may dump the contents into a generic bucket or skip them. "My Toolkit" instead of "Skills" does the same damage. Save the personality for your bullet points, where a human reads it and software does not need to classify it.

Order and dates also signal structure

Inside each job, keep a predictable shape: title, company, location, dates, then bullets. Write dates in a consistent, unambiguous format. Jan 2022 - Present is fine for a human, but for a machine prefer something stable like 2022-01 to 2024-03, or at minimum keep one format across the whole document. Mixing "2022," "March 22," and "Spring 2023" forces the parser to guess your timeline, and guessing is where months of experience disappear.

Step 3: Keep it one column

Two-column resumes are the prettiest trap in the business. A skills sidebar on the left, experience on the right, clean and modern. And then a parser reads it left to right, top to bottom, like text, and your sidebar gets stitched into the middle of your job history.

The result is a scrambled record. Your Python skill lands inside a sentence about your 2021 promotion. Your degree merges with a list of tools. The information is all present, technically, just shuffled into nonsense.

The provided research here is honest about limits: there is no peer-reviewed, audited figure for how often multi-column layouts fail across every ATS, and you should be wary of anyone quoting a precise rejection rate as settled fact. What the sources do support is the mechanism. Tables, text boxes, multi-column layouts, and graphics raise the risk of misread or lost structure during parsing. Plain DOCX is described in that source set as the safest format. One vendor, ResumeAdapter, puts the table-and-column failure share at roughly 23 percent against about 4 percent for plain DOCX, but treat those as unverified vendor estimates rather than proven numbers.

The fix is dull and effective

• One column, top to bottom.
• No text boxes. Anything inside a text box may be invisible to the parser, because it sits outside the main text flow.
• No tables for layout. A table used to align dates can read as a jumble of cells.
• Keep contact details in the body, not the header or footer. Some parsers ignore header and footer regions entirely, which is a cruel place to hide your phone number.

You can still make it look good. One-column does not mean ugly. It means the reading order matches the visual order, which is the whole point.

Step 4: Name your fields with structured data

Everything above makes a document easier to parse. This step removes the parsing problem entirely. Instead of hoping software extracts the right fields from your layout, you hand it the fields already labeled.

This is the leap from a document to data. A PDF is a thing a machine has to interpret. Structured data is a thing a machine already understands, because every value comes tagged with what it is.

What structured career data looks like

A structured resume is a file where your name is explicitly marked as a name, your job title as a title, your start date as a date. No interpretation needed. Here is the shape, in cv.json, the open standard built for exactly this:

{
  "basics": {
    "name": "Ashley Carter",
    "label": "Senior Product Designer",
    "email": "[email protected]",
    "location": { "city": "Berlin", "countryCode": "DE" },
    "profiles": [
      { "network": "LinkedIn", "url": "https://linkedin.com/in/ashleycarter" }
    ]
  },
  "work": [
    {
      "name": "Northwind Labs",
      "position": "Senior Product Designer",
      "startDate": "2022-01",
      "endDate": "",
      "highlights": [
        "Led the redesign of the onboarding flow",
        "Mentored three junior designers"
      ]
    }
  ],
  "meta": { "version": "1.2", "canonical": "https://livelink.cv/ashley/cv.json" }
}

Notice what just happened. There is no guessing. "position" is the job title, full stop. "startDate" is a date in a fixed format. An AI recruiter or ATS reading this does not parse, it just reads keys, the way one program reads another. The ambiguity that breaks PDF parsing is gone, because there is no layout to misread.

The fields, and what is actually required

The cv.json standard covers basics, work, education, skills, projects, languages, certificates, plus an availability block (open-to-work status, target roles, work type, visa needs) and a meta block (version and canonical URL). Only basics and meta are required. Everything else is optional, so a one-job graduate and a twenty-year veteran both produce valid files.

It is open, MIT licensed, and field-compatible with JSON Resume, the community schema at jsonresume.org. If you already have a JSON Resume file, your work, education, and skills arrays carry straight over. The spec lives at github.com/freecvorg/cv-json, current version 1.2. Contact details are hidden by default, which matters: you publish the structure without spraying your email across the open web.

A PDF asks software to interpret your career. Structured data hands it your career already labeled. One of those fails quietly; the other does not.

Step 5: Publish at a stable URL and add discovery

Structured data sitting on your hard drive helps no one. The point of cv.json is that it lives at a fixed web address an AI recruiter or ATS can fetch on demand, like an API for you.

So you publish it at a stable URL. Something like https://livelink.cv/ashley/cv.json. That address does not change when you get a new job. You update the file behind it, and anyone who has the link, or any agent that discovers it, always sees your current self. No re-uploading a PDF to six job boards every time you change a title.

Three ways software finds the file

Publishing is half of it. Discovery is the other half, and cv.json ships three mechanisms so a crawler or agent does not have to guess your URL:

1. A <link rel="alternate"> tag in your portfolio page's HTML head, pointing at the JSON, the same trick RSS feeds use to announce themselves.
2. A /.well-known/cv.json manifest, the standard web location for machine-readable metadata about a site.
3. An X-CV-Version HTTP header, so a tool can check your version without downloading the whole file.

It also serves with open CORS, meaning a browser-based tool from another domain is allowed to fetch it. Here is the discovery tag, the one line that turns a portfolio into something agents can follow:

<link rel="alternate"
      type="application/json"
      href="https://livelink.cv/ashley/cv.json"
      title="cv.json">

One honest note. No specific ATS vendor is known to ingest cv.json as a native format today, and you should not believe anyone who claims Workday or Taleo already read it. The standard is designed for AI recruiters and ATS to read, and it is built for where hiring is going. The mechanics, real text, named fields, a fetchable URL, are exactly what every parser and every LLM-based screener wants. You are skating to the puck.

A quick reality check on ATS today

It is worth being precise about how today's systems actually behave, because the folklore is wrong in both directions.

ATS use is mainstream in enterprise hiring. Commonly cited industry summaries suggest that nearly 99 percent of Fortune 500 companies use an ATS, that around 70 percent of large companies and about 75 percent of recruiters use one. Those are secondary compilations, not audited census data, so treat them as directional. The defensible version is simpler: if you apply to a large employer, software almost certainly touches your resume first. The big names in that market include Workday, Taleo, Greenhouse, Lever, iCIMS, and Ashby, though reliable market-share splits between them are not public, so nobody should tell you one of them "dominates."

The robot-rejection myth

The famous line that "75 percent of resumes are rejected by an ATS" is not supported by peer-reviewed evidence. It gets repeated because it is scary and round. What modern systems mostly do is rank, sort, and filter, and the actual early-stage cuts often come from knockout questions employers set, such as work authorization or years of experience, not a blanket auto-reject on your formatting. In one 2025 recruiter sample, 92 percent of ATS users said their system does not auto-reject based on resume content, though that is a small vendor-published interview, not a population rate.

So the ATS is less a bouncer and more a librarian who files you, then a recruiter searches the shelves. If your file got mis-shelved during parsing, you are not rejected. You are unfindable, which is worse, because nobody decided anything about you at all.

AI changes the stakes, not the principle

By 2025 and 2026, AI inside recruiting is no longer experimental. A 2026 Lever piece frames AI candidate matching, interview summarization, and predictive analytics as table stakes in modern ATS evaluation. Bullhorn, citing the 2026 GRID Industry Trends Report, says 78 percent of staffing firms growing revenue by more than 25 percent have AI tools embedded in their ATS, though that applies to fast-growing staffing firms, not every employer. One 2026 summary, citing SHRM, reports AI adoption in HR tasks rising to 43 percent in 2025 from 26 percent in 2024.

The pattern across all of it: these systems ingest your resume, parse it into structured fields, then match, rank, and summarize. Every one of those steps gets easier and more accurate when you hand over clean structure instead of a decorative PDF. An LLM screener reading your cv.json is not guessing where your skills are. It is reading a skills array.

A worked example: same person, two formats

Picture Ashley, the senior product designer above. In a two-column PDF with a skills sidebar and date columns in a table, a parser might extract her job title correctly but scatter her skills into the wrong job, lose her start dates inside table cells, and skip her email because it lived in the header. A recruiter searching for "product designer Berlin" might not surface her at all, because her location got merged into a bullet point.

Now the same Ashley with a clean one-column PDF for human eyes plus a published cv.json at a stable URL. The PDF parses cleanly because the reading order matches the visual order. The JSON needs no parsing at all: basics.location.city is "Berlin," her skills sit in their own array, her dates are 2022-01 formatted. Same career, same person, wildly different odds of being found.

Edge cases worth handling

• Career gaps. Leave the gap visible with honest dates rather than hiding it in fuzzy formatting. A parser handles a clean gap fine. It handles "2019 to 2023ish" badly.
• Multiple roles at one company. List each as its own work entry with its own dates, rather than nesting promotions inside one block, so each title is captured separately.
• Special characters and accents. In JSON they are just UTF-8 text and survive fine. In a PDF with a non-embedded font, an accented name can corrupt, so embed fonts or rely on the JSON as the source of truth.
• Contact privacy. Because cv.json hides contact details by default, you can publish the file publicly and still control who reaches you, which is the opposite of pasting your phone number into a PDF on a job board forever.

How a parser actually reads your file, start to finish

It helps to see the pipeline, because once you know the steps you can guess where yours will break. A resume parser does roughly four things in sequence, and a structured cv.json short-circuits most of them.

The four stages

1. Text extraction. The system pulls raw characters out of your file. This is where an image-only PDF dies on arrival, because there are no characters to pull, only pixels. It is also where a non-embedded font turns "finance" into a question mark.
2. Block detection. The extracted text is grouped into chunks by position on the page. A two-column layout confuses this stage the most, because the parser has to decide whether two side-by-side blocks are one reading flow or two, and it usually guesses one.
3. Section classification. Each block gets labeled: this is experience, that is education, this is a skills list. Standard headings drive this. A heading like "My Toolkit" lands in an unknown bucket, and unknown buckets are where content goes to be ignored.
4. Field mapping. Inside each classified block, the parser hunts for entities: a company name, a title, a date range, a degree. This is the guessing-heavy stage, and it is the one that gets dates wrong, splits a job title across two fields, or attaches a skill to the wrong employer.

Now overlay cv.json on that pipeline. Stage one is trivial, because JSON is already text. Stage two does not exist, because there is no layout to detect. Stage three is solved, because work is literally named work. Stage four is gone, because position already holds the title and startDate already holds the date. You have not made the parser smarter. You have removed the parts of its job where it fails.

Every parsing failure happens at a stage where the software has to guess. Structured data deletes the guessing stages, so there is nothing left to fail at.

Make it readable for LLM screeners, not just classic parsers

Classic ATS parsers and AI screeners want overlapping things, but the AI layer adds a few wrinkles worth knowing. The evidence is clear that by 2025 and 2026 these systems do more than file you. They match you against a role, rank you, and summarize you for a recruiter. That summary is generated from whatever the model could extract, so the cleaner your input, the more faithful the summary.

Write for extraction and for meaning at once

An LLM reading a bullet like "Responsible for various stakeholder activities" extracts almost nothing, because there is nothing concrete to anchor on. A bullet like "Cut onboarding drop-off by reworking the three-step signup into one screen" gives the model a verb, an outcome, and a method, which is exactly the kind of content that survives summarization intact.

Two practical habits help here. First, front-load each bullet with a concrete action, not a duty. Second, keep skills as plain comma-or-line-separated words rather than rated graphics, because the model reads "Figma, user research, design systems" as three skills and reads five filled dots as nothing. None of this is AI-specific magic. It is the same discipline that helped human readers, now paying off twice.

Why the structured file wins with AI specifically

An LLM handed your cv.json does not have to reconstruct your career from a flattened page. It reads work as a list of jobs, each with a position, a date range, and highlights. The model spends its effort on judgment, matching you to the role, rather than on detective work, figuring out where your last title ended. The honest framing holds: no named ATS vendor ingests cv.json natively yet, but any AI agent or tool that fetches the file reads it directly, and that is a growing share of how candidate data gets consumed.

Common mistakes that quietly break parsing

Most resumes are not killed by one big error. They are nibbled to death by small, well-meaning choices. Here are the ones that show up again and again.

• Contact details in the header or footer. Some parsers skip those regions entirely. Your email and phone belong in the body, near the top.
• Skill ratings as dots, bars, or stars. A parser reads shapes, not proficiency. Write "advanced" or "native" as a word if level matters.
• Dates in mixed formats. "2021," "Mar 2022," and "Summer '23" in the same document force the parser to guess a timeline, and guessing loses months.
• A logo or headshot doing real work. Decorative is fine. But never put a fact, like a job title or a location, inside an image, because that fact becomes invisible.
• Tables to align dates or columns. Visually neat, structurally a trap. Cells can read as a jumble in the wrong order.
• Special characters in a non-embedded font. Accents and ligatures corrupt during extraction. Embed the font, or treat the JSON as the canonical copy.
• A filename like "resume-final-v3-USE-THIS.pdf". It will not break a parser, but a clean name like "Ashley-Carter-Resume.pdf" is the kind of detail that signals care to the human at the end.
• One giant text box holding the whole resume. Content outside the main text flow can be dropped wholesale. Use the document body.

Notice the theme. None of these are about being unqualified. They are about being unreadable, which is a fixable problem and a maddening reason to lose.

The standards landscape, briefly and honestly

You will hear about several "resume standards." None has won broad ATS adoption, and the market stays fragmented and system-specific. Here is the grounded version.

JSON Resume (jsonresume.org) is a community-driven open schema and the closest thing to a shared developer convention; real employer adoption is limited and not well measured. Europass is a European Commission CV format, useful in the EU, not a dominant global interchange standard. HR-Open Standards LER-RS is an emerging interoperability standard, more institutional than mass-market. schema.org is best understood as structured-data markup that aids discoverability and parsing, not a canonical applicant-data format. HR-XML mattered historically in HR interoperability but is not a mainstream consumer resume format today.

So cv.json is not claiming to be the one ring that rules them all. It is claiming something more useful: an open, MIT-licensed, JSON Resume-compatible file at a stable URL with built-in discovery, designed for the AI-driven hiring tools that are actually arriving. You lose nothing by adopting it, because it complements the clean PDF you already need.

Your checklist, in order of payoff

1. Confirm every word is selectable text, not an image. Fix this first; it breaks everything else.
2. Rename sections to standard labels: Experience, Education, Skills, Projects, Certifications.
3. Collapse to one column. Kill text boxes, layout tables, and header-or-footer contact details.
4. Use one consistent, unambiguous date format throughout.
5. Generate a structured cv.json file with at least basics and meta.
6. Publish it at a stable URL and add the three discovery hooks: the link rel="alternate" tag, the /.well-known/cv.json manifest, and the X-CV-Version header.

Steps one through four make today's parsers stop choking. Steps five and six make you legible to whatever reads resumes next. You do not have to pick. Keep the polished PDF for the human, and stand up the JSON for the machine, and stop losing to a parser that simply could not see you.

The fastest path is to not hand-write any of this. Build your CV once at freecv.org/builder for free, and it produces both a clean, one-column, real-text PDF and a published cv.json at a stable URL with discovery already wired in. Make yourself readable to the software, then go be impressive to the human.