PDF vs JSON Resume: What AI Recruiters Prefer

Picture two resumes that say the exact same thing. Same name, same job titles, same five years of experience. One is a PDF. One is a JSON file. To you, on a screen, they look identical, or close to it. To a machine, they could not be more different. One is a photograph of words. The other is the words themselves, labeled and sorted.

That gap is the whole story. A PDF resume is a fixed visual layout that machines must OCR and guess at, while a JSON resume is structured, labeled data a parser reads field by field with no guessing. The PDF hides meaning inside a picture. The JSON hands meaning over directly. And as more of hiring runs through applicant tracking systems and AI screeners, the format you choose stops being a cosmetic decision. It becomes a parsing decision.

So let's go under the hood. We'll look at what each format actually is to a machine, what AI recruiters tend to prefer and why, where PDF still earns its keep, and how cv.json lets you stop choosing between the two.

What a PDF actually is to a machine

PDF stands for Portable Document Format. Adobe shipped it in 1993, and its entire job was to make a document look the same everywhere. Same fonts. Same margins. Same line breaks on every screen and every printer. For a paper-era document, that's a feature. For data, it's a cage.

Here's the catch. A PDF describes where glyphs sit on a page, not what those glyphs mean. The file knows that the characters "Senior Engineer" appear at a certain x and y coordinate in a certain font size. It does not know that "Senior Engineer" is your job title. There's no label saying "this is a role" or "this date is a start date." A human reading it infers all that from layout and context. A machine has to reconstruct it.

That reconstruction is called parsing, and with PDFs it's basically reverse-engineering. The parser reads a soup of positioned characters and tries to rebuild the structure a designer pulled apart. When the layout is a single clean column of text, that often works fine. When it's two columns, sidebars, tables, text boxes, or icons, the parser can stitch lines together in the wrong order, drop a column, or merge your skills into your address.

A PDF tells a machine where the ink goes. It never tells the machine what the ink means. The meaning has to be guessed back out, and guessing is where resumes break.

There are two flavors of PDF, and the difference matters. A text-based PDF, the kind exported by Word or a resume builder, has a selectable text layer underneath the visuals, so a parser can at least pull characters out directly. An image-based PDF, the kind you get when someone scans a printout or exports a design as a flat picture, has no text layer at all. To read it, software must run OCR, optical character recognition, which is the same guess-the-letters technology used on photographed receipts. OCR is good now. It's still guessing. A lowercase l, an uppercase I, and the number 1 are a coin toss in some fonts.

So when people say "ATS can't read my PDF," they're usually half right. The PDF can often be read. The trouble is that the structure inside it, the part that says which words are skills and which are employers, has to be inferred. And inference fails quietly. You never see the error. You just don't hear back.

What a JSON resume actually is to a machine

JSON stands for JavaScript Object Notation. It's a plain text format for structured data, and it's the lingua franca of basically every API on the internet. When your phone checks the weather, when an app loads your profile, when one system talks to another, the data crossing that wire is almost always JSON. It's boring, universal, and machines love it.

The reason machines love it is the reason it matters here: in JSON, every piece of data is labeled. Nothing is implied by position on a page. Your job title is literally inside a field called position. Your employer is inside name. Your start date is inside startDate in a fixed format. There's no guessing, no OCR, no reverse-engineering of columns. The parser reads the label, takes the value, done.

Here's a slice of what a work entry looks like in a structured resume:

{
  "work": [
    {
      "name": "Northwind Logistics",
      "position": "Senior Software Engineer",
      "startDate": "2021-03",
      "endDate": "2024-11",
      "summary": "Led the rebuild of the dispatch platform.",
      "highlights": [
        "Cut average route-calculation time from 9s to under 2s",
        "Mentored four engineers, two promoted within a year"
      ]
    }
  ]
}

Look at what a machine gets here for free. It knows the company name without guessing. It knows the dates are dates, and in a sortable order, because 2021-03 follows the ISO 8601 standard rather than "March 2021" or "Mar '21" or "03/2021," all of which a PDF parser has to normalize and frequently mangles. It knows the highlights are a list, not one run-on paragraph. The structure is the meaning, and the meaning is handed over, not excavated.

The most established open spec for this is JSON Resume, hosted at jsonresume.org. It's a community-driven schema that's been around for years, with a defined shape for basics, work, education, skills, and more. It proved the idea works. Its real-world employer adoption stays limited and isn't well measured, but the schema itself is solid, and it's the foundation cv.json builds on.

What actually happens when a parser opens your resume

It helps to watch the two formats move through the same pipeline, step by step, because the difference isn't abstract. It's a count of stages, and every stage is a place to lose data.

Start with the PDF. Stage one, the system opens the file and checks whether there's a text layer. If there is, it extracts the raw characters along with their coordinates. If there isn't, because someone scanned a printout, it runs OCR first and accepts whatever the letter-guesser returns. Stage two, the parser groups those loose characters into lines and blocks using the x and y positions. Stage three, it tries to classify each block: is this a heading, a job title, a date range, a bullet, a phone number? Stage four, it maps those guesses onto the database fields the ATS actually stores. Four stages, and stages one through three are all inference. Each one can quietly drop or scramble something.

Now the JSON. Stage one, the system fetches the file and confirms it's valid JSON. Stage two, it reads the labeled fields straight into its database. Two stages, zero inference. There's no "is this a heading" guess because the data already told it. The position field is the title. The startDate field is the start date. Nothing has to be classified because nothing was ever flattened into a picture in the first place.

A concrete failure: the two-column scramble

Here's where the abstract gets painful. Say your PDF puts skills in a left sidebar and work history in a wider right column, a hugely popular template style. A human eye reads the right column as the main content and treats the sidebar as a side note. The parser doesn't have eyes. It often reads strictly by vertical position, left to right across the full page width. So it can produce a line like "Python, AWS, Docker Senior Engineer at Northwind Logistics 2021," gluing your skills onto the front of your first job. Now your job title is buried mid-string, your skills are attached to the wrong section, and the date floats loose. The ATS stores that mess. You never see it. The provided research is explicit that tables, text boxes, multi-column layouts, and graphics increase the risk of misreading or loss of structure during parsing.

With cv.json there is no column to read across, because there's no column at all. Skills live in a skills array, work lives in a work array, and the visual layout is a rendering choice made later by whatever displays the data. The scramble can't happen because the thing that causes it, position-based inference, never runs.

What AI recruiters actually prefer

Let's be precise about who's reading resumes now, because "AI recruiter" gets thrown around loosely. The realistic picture, supported by 2025 and 2026 industry reporting, is that modern ATS and AI stacks treat a resume as an input document to be parsed into structured fields, then run matching, ranking, summarization, and workflow automation on top of those fields. The first step, always, is turning your resume into structured data.

And that's the punchline. Every system, PDF-fed or not, is trying to reach the structured state that JSON already starts in. Feed it a PDF and step one is parsing, with all the guessing that entails. Feed it JSON and step one is already done. You've handed over the finished product instead of the raw material.

ATS use is mainstream in enterprise hiring, especially at large employers. Commonly cited industry figures suggest nearly all Fortune 500 companies run an ATS, that around 70% of large companies use one, and that roughly three in four recruiters use an ATS or similar recruiting tool, though these are secondary-source compilations best read as directional rather than audited census data. The names you'll meet in that market include Workday, Taleo, iCIMS, Greenhouse, Lever, and Ashby. Each parses resumes its own way, with its own quirks, which is exactly why a format that doesn't need interpreting is safer across all of them. Worth flagging honestly: the public sources don't give reliable market-share percentages for any one of those vendors, so treat "vendor X dominates" claims with suspicion.

Every screening system is trying to turn your resume into structured data. A PDF makes it work for that. JSON hands it over. You're not fighting the parser. You're skipping it.

The AI layer raises the stakes. Bullhorn's 2026 GRID Industry Trends Report found that 78% of staffing firms growing revenue by more than 25% have AI tools embedded in their ATS, though that's fast-growing staffing firms, not all employers. One 2026 ATS summary, citing SHRM, reported AI adoption in HR tasks jumping to 43% in 2025 from 26% the year before. Treat the SHRM figure as a secondary citation until you check the original. The direction is the point: AI in recruiting is no longer experimental, it's embedded in how candidates get matched, ranked, and summarized.

Large language models, the engines behind these AI screeners, are themselves trained on oceans of structured text, and JSON is among the most native formats they consume. Hand an LLM clean labeled fields and it reasons over them cleanly. Hand it a PDF and you've added a lossy translation step before any reasoning starts. So when we say cv.json is designed for AI recruiters and ATS to read, that's not marketing. It's the format the back end was already trying to build.

One honest caveat, because accuracy demands it. The widely repeated line that "75% of resumes are rejected by an ATS" isn't backed by peer-reviewed evidence, and you should be skeptical of it. In one 2025 recruiter sample, 92% of ATS users said their system does not auto-reject based on resume content. Most filtering happens through knockout questions employers set, plus ranking and sorting. So JSON's edge isn't that it rescues you from a robot delete button. It's that it gives every system cleaner, more complete data to rank and surface you with.

When PDF still matters

None of this means you burn your PDF. PDF wins decisively at one thing, the thing it was built for: looking good to a human. And humans still do a lot of the deciding.

A recruiter who opens your application wants to see a designed document. Typography, spacing, a clean hierarchy, maybe a tasteful accent color. JSON shows them none of that. JSON is data, not design. Nobody wants to read raw curly braces over coffee, and frankly nobody should have to.

Here's where PDF stays essential:

• Email attachments and direct sends. When a hiring manager asks you to email a resume, they want a polished file they can open, skim, and forward. That's a PDF.
• Printing. Career fairs, in-person interviews, panels that like paper in hand. PDF was literally invented for consistent printing.
• Portfolios and creative roles. Designers, art directors, anyone whose layout is part of the pitch. The visual is the message.
• Application forms that demand a file upload. Plenty of portals still take only a document. You give them a clean, single-column, text-based PDF, not an image-based one, and not a two-column design.

The trick with a PDF resume is to make it parser-friendly even though it's a picture. Single column. Standard fonts. No tables, text boxes, or graphics holding your actual content. Real selectable text, never a flattened image. Dates written plainly. The provided research is clear that tables, multi-column layouts, and graphics increase the risk of misreading during parsing, while plain text-first formats are described as the safest. A well-built PDF parses far better than a designer's nightmare PDF. It still parses worse than data that never needed parsing.

Common mistakes that quietly wreck PDF parsing

If you're going to keep a PDF, and you should, the failures below are the ones that turn a good resume into a garbled database row. None of them show up when you eyeball the file. They only show up in the ATS, where you can't see. Run this as a checklist before you upload anything.

• Two columns or a sidebar. The single most common cause of scrambled output. Collapse to one column for any version going through an upload portal. Save the two-column beauty for human email sends.
• Real content trapped in tables. A table used for layout, say experience on the left and dates on the right, reads unpredictably. Some parsers walk it row by row, some column by column. Use plain paragraphs and let the date sit on the same line as the role, in text, not in a cell.
• Text boxes and shapes. A "skills" box floating in the corner often gets read out of order or skipped. Anything load-bearing belongs in the main text flow.
• Contact details in the header or footer. Some parsers ignore header and footer regions entirely, so a phone number or email living up there can vanish. Put contact info in the body, near the top.
• Icons standing in for labels. A little phone glyph next to a number means nothing to a parser. Spell out "Phone" or just present the number plainly. Same with envelope icons for email and pin icons for location.
• Creative date formats. "Summer 2023," "Q1 '22," or "ongoing" force the parser to guess. Write a clear range like "Mar 2021 to Nov 2024," and stay consistent across every entry.
• A flattened, image-based export. Exporting your design as a single picture, or scanning a printout, kills the text layer and forces OCR. Always export real, selectable text. Quick test: open the PDF and try to highlight a line. If you can't select it, the machine can't read it cleanly either.
• Exotic fonts and ligatures. Decorative fonts can encode characters in ways that extract as gibberish, and fancy ligatures can fuse letters. Stick to common, well-supported fonts.

The blunt summary: every item above is a place where a picture forces a machine to guess. A cv.json sidesteps the entire list, because there's no header region to skip, no column to misread, no icon standing in for a label. The data is labeled, so there's nothing left to guess.

The honest comparison, side by side

Let's lay it out plainly, no spin.

How a machine gets the data

PDF: the machine OCRs or extracts text, then infers structure from layout. Error-prone on anything but a simple single column. JSON: the machine reads labeled fields directly. No inference, no OCR, no layout guessing.

How a human sees it

PDF: designed, formatted, pleasant to read. JSON: raw data, unreadable to most people without a renderer turning it back into a page. This is PDF's real and lasting advantage.

Date and field reliability

PDF: dates appear in whatever style you typed, and parsers normalize them with mixed success. Fields are guessed from position. JSON: dates follow ISO 8601, fields are explicit. A machine sorts your roles correctly every time.

What happens to multi-column layouts

PDF: a two-column design can be read top to bottom across both columns, scrambling your skills into your job history. JSON: there are no columns. There's only data. Layout is a rendering choice made later, separate from the content.

Updating

PDF: change a job title, re-export, re-upload everywhere you applied. Every copy is a frozen snapshot. JSON: update one file at one URL, and anyone reading that link sees the current version. The data is live, not a photocopy.

File size and portability

PDF: kilobytes to megabytes, especially with embedded fonts and images. JSON: usually a few kilobytes of plain text. It moves across systems the way every API payload does, because it is one.

Versioning and authority

PDF: nothing inside the file says which copy is current. The "resume_final_v3_REAL.pdf" naming war exists for a reason. JSON: a cv.json carries a meta.canonical field pointing at the one authoritative URL, plus a version number, so any reader knows it's looking at the live, official copy.

So the scoreboard is honest. PDF wins on human presentation. JSON wins on everything a machine touches: extraction accuracy, field reliability, date handling, updating, portability, and versioning. The question was never which format is better. It's which job you're doing in that moment, impressing a person or feeding a parser.

A worked migration: PDF to cv.json in practice

This is less work than it sounds, because the content already exists in your PDF. You're relabeling it, not rewriting it. Here's the path from a finished PDF to a published, machine-readable cv.json.

1. Start from your existing content. Take the text you already have, your name, contact details, each job with its title, employer, dates, and bullets, your education, and your skills. Nothing new to invent.
2. Drop it into structured fields. Map each piece to its field: name and contact go in basics, each job becomes an object in work, schools go in education, and so on. A builder does this for you, but it's worth understanding what's happening underneath.
3. Fix the dates to ISO 8601. "March 2021" becomes 2021-03. This is the single highest-value cleanup, because it's the field PDF parsers mangle most.
4. Add the availability signals. This is the part a PDF can't carry. Flag whether you're open to work, your target roles, your preferred work type, and your visa situation, all as machine-readable values.
5. Publish at a stable URL and keep the PDF. The cv.json lives at one link you update once. The PDF stays for human sends. You now have both.

Here's a fuller cv.json showing how the pieces sit together, including the basics block, a skills array, and the availability signals that make it useful to an AI recruiter:

{
  "basics": {
    "name": "Ashley Carter",
    "label": "Backend Engineer",
    "location": { "city": "Berlin", "countryCode": "DE" }
  },
  "skills": [
    { "name": "Backend", "keywords": ["Python", "Go", "PostgreSQL"] },
    { "name": "Infrastructure", "keywords": ["AWS", "Docker", "Terraform"] }
  ],
  "availability": {
    "openToWork": true,
    "roles": ["Backend Engineer", "Platform Engineer"],
    "workType": ["remote", "hybrid"],
    "visa": "EU work authorization, no sponsorship needed"
  },
  "meta": {
    "version": "1.2",
    "canonical": "https://livelink.cv/ashley/cv.json"
  }
}

Notice what an AI recruiter gets from that availability block that no PDF can hand over cleanly. It doesn't have to infer from a summary line that you're job hunting, or guess whether "open to relocation" means remote is fine. The status is a boolean. The roles are a list. The work type is a list. The visa note is a plain string. A machine reads intent, not vibes.

Why cv.json gives you both from one link

This is where you stop choosing. cv.json is an open, MIT-licensed standard for publishing your resume as one structured JSON file at a stable web address, for example livelink.cv/ashley/cv.json. It's built by FreeCV, the spec lives at github.com/freecvorg/cv-json, and the current version is 1.2. One file, one link, machine-readable by default.

The design is deliberately simple. Your data lives in fields like basics, work, education, skills, projects, languages, certificates, an availability block, and a meta block. Only basics and meta are required. The schema is field-compatible with JSON Resume, so you're not betting on something exotic, you're building on the established open spec and extending it for an AI-recruiter world.

Discovery is the part that makes it work like real web infrastructure rather than a file you have to remember to send. A cv.json is findable three ways:

• A link rel="alternate" tag in the HTML of your portfolio page, the same mechanism RSS feeds use, so a crawler on your page finds the data version automatically.
• A /.well-known/cv.json manifest, the standard web convention for "here's the canonical machine-readable thing at this domain."
• An X-CV-Version HTTP header, so a system can check which spec version it's getting before it parses a byte.

CORS is open, meaning any application is allowed to fetch it from the browser without being blocked. The availability block is genuinely forward-looking for AI hiring, because it carries machine-readable signals like open-to-work status, target roles, preferred work type, and visa needs. An AI recruiter doesn't have to read between the lines of your summary to figure out you're looking. The data says so:

{
  "availability": {
    "openToWork": true,
    "roles": ["Backend Engineer", "Platform Engineer"],
    "workType": ["remote", "hybrid"],
    "visa": "EU work authorization, no sponsorship needed"
  },
  "meta": {
    "version": "1.2",
    "canonical": "https://livelink.cv/ashley/cv.json"
  }
}

Privacy is handled sensibly. Contact details are hidden by default, so publishing structured data doesn't mean spraying your phone number across the open web. You control what's exposed. And because meta.canonical points at the one true URL, every reader knows which copy is authoritative, no stale forks floating around.

Keep the PDF for the humans. Publish the cv.json for the machines. One link feeds the AI recruiters and ATS clean data, and you stop maintaining a dozen frozen snapshots.

Here's how it fits together in practice. You keep your beautiful PDF for the email sends, the printouts, the portals that demand a file. You publish your cv.json at a stable link for everything machine-driven: the AI screeners, the parsing pipelines, the recruiters whose tools fetch structured data, the future where hiring keeps moving this direction. When a job title changes, you edit the JSON once and every reader of that link is current. The PDF is your handshake with people. The cv.json is your handshake with the machines that increasingly decide who gets to shake hands at all.

The honest framing matters, so here it is plainly. We're not claiming specific ATS vendors already read cv.json today. The market for resume-data standards is still fragmented and system-specific, with no single dominant open format in broad ATS use, and other efforts like Europass, schema.org markup, and the older HR-XML each occupy their own narrow lane without mass-market resume adoption. What we're saying is that cv.json is designed for AI recruiters and ATS to read, and that it points exactly where hiring is heading: toward structured data that machines consume directly instead of pictures they squint at.

So you don't have to pick a side in the PDF-versus-JSON fight. The fight was a false choice. Keep the PDF that looks great to a person, and add the cv.json that reads perfectly to a machine, from one stable link you update once. You can build both, free, in a few minutes at freecv.org/builder, and give every reader, human or AI, exactly the format they were hoping for.