Resume Standards Compared: JSON Resume to cv.json

Most resumes are a paragraph wearing a costume. They look like data. Job title, dates, bullet points, a skills row. But underneath it's just styled text, and the moment a machine tries to read it, the costume falls off and the parser has to guess what's a heading and what's a company name.

A schema fixes the guessing. It says: this string is the job title, this one is the employer, these dates are start and end, and here is where skills live. Same facts, predictable home for each one. That's the whole idea, and it's older than you'd think. HR-XML, the first serious attempt at machine-readable hiring data, dates to 1999.

A resume schema is an agreed structure for describing a person's career as data, so the same facts about work, education, and skills can be read the same way by humans and machines without anyone guessing where the job title lives.

So why are there five of these things instead of one? Because they were built by different people for different jobs. A web vocabulary, a developer's side project, a government program, an HR standards body, and a web-native format aimed at AI recruiters. They overlap, they disagree, and only some of them produce a file you can actually publish. Let's go through them in order, then pick.

schema.org: the vocabulary, not the resume

schema.org is the shared vocabulary that Google, Bing, Yandex, and a long list of crawlers agreed on back in 2011. It defines types like Person, Organization, EducationalOccupationalCredential, and JobPosting. You drop it into a web page as JSON-LD or microdata, and search engines use it to understand what the page is about.

Here's the catch that trips people up. schema.org has a Person type with properties like jobTitle, alumniOf, and knowsAbout. It does not have a clean, ordered way to describe a full work history with bullet points, start and end dates per role, and the structure a resume actually needs. The reality here is blunt: schema.org is used for discoverability and parsing assistance, not as a canonical applicant-data format. There is no adoption rate for schema.org as a resume standard because that isn't what it's for.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Ashley Carter",
  "jobTitle": "Product Designer",
  "knowsAbout": ["Figma", "design systems", "user research"],
  "alumniOf": "University of Toronto"
}
</script>

That's genuinely useful for a personal site's SEO. A crawler reads it and knows who the page is about. But notice what's missing. No dated job list. No way to say you worked at one company for three years and another for two, in order, with what you did at each. You can bolt on OrganizationRole and workLocation and nest things, but you're now hand-building structure the spec never designed for resumes.

Use schema.org for what it's good at: marking up the page so machines know it describes a person. Don't reach for it as your resume's source of truth. It's the dictionary, not the document.

JSON Resume: the developer favorite

JSON Resume, at jsonresume.org, is the one engineers actually love. It started as a community open-source project, MIT-licensed, with a simple promise: write your resume once as a JSON file, then render it into any theme. There are dozens of community themes. You run a CLI, point it at your resume.json, and out comes HTML or a PDF.

The schema is clean and readable. Top-level keys like basics, work, education, skills, projects, languages, awards, and references. Each work entry has name, position, startDate, endDate, summary, and a highlights array for bullets. If you've ever wanted your resume in version control with a clean git diff every time you change a job title, this is the format that made that normal.

{
  "basics": {
    "name": "Ashley Carter",
    "label": "Product Designer",
    "email": "[email protected]"
  },
  "work": [
    {
      "name": "Northwind Studio",
      "position": "Senior Product Designer",
      "startDate": "2022-03",
      "endDate": "2025-01",
      "highlights": [
        "Led the redesign of the onboarding flow",
        "Built and maintained the shared component library"
      ]
    }
  ]
}

So what's the limitation? Two things. First, the honest read here: JSON Resume's real-world employer adoption is limited and not well measured. Recruiters aren't asking for your resume.json. It's a developer convenience and a rendering pipeline, not a format hiring systems ingest at scale.

Second, it has no built-in story for the part that matters most in 2026: being found and read on the web by an AI recruiter. There's no standard discovery mechanism, no opinion on whether your contact details should be hidden by default, no field for whether you're open to work. JSON Resume answers "how do I store my resume as data and render it." It doesn't answer "how does a machine find and read my career on the open web." That gap is exactly where the next two standards, and then cv.json, come in.

Europass: official, comprehensive, heavy

Europass is the European Commission's CV and profile format, part of a wider digital credentials framework that's been running for years. It's official in a way none of the others are. It's backed by a government body, used across EU education and mobility programs, and it covers far more than a resume: language self-assessment grids, mobility records, digital credentials signed by issuing institutions.

If you're a student applying through an EU exchange program, or moving between member states, Europass is genuinely the right tool. It speaks the language of European education systems and it carries verifiable credentials in a way a plain resume never could. It also exports to a structured format you can move between Europass-aware systems.

But it's heavy. The format is comprehensive because it has to serve credentials, qualifications frameworks, and cross-border recognition, not just "here's my job history." And the evidence is clear: there's no evidence it functions as a dominant global ATS interchange standard. It's a regional, institution-facing format. Outside Europe, most hiring systems have never heard of it. Inside Europe, it's a profile and credential tool more than a file you publish for an AI to crawl.

Official does not mean universal. Europass is real and backed by a government, but a US startup's Greenhouse pipeline isn't reading Europass XML.

HR-Open Standards and LER-RS: the most official one

If schema.org is the dictionary and Europass is the government program, HR-Open Standards is the standards body. HR-Open is the organization that grew out of the old HR-XML work, and it publishes interoperability standards for HR data: payroll, recruiting, time, benefits. Serious, vendor-grade plumbing for systems that talk to other systems.

The relevant piece here is LER-RS, the Learning and Employment Record Resume Standard. It's an attempt to define a rigorous, structured resume record that can carry verified learning and employment data between systems, including credentials that have been validated by an issuer rather than just typed in by the candidate. On paper it's the most "correct" of everything in this article. It's built by the right body, for exactly this interoperability problem.

And yet. There are no public adoption metrics for HR-Open LER-RS, which means the safest honest description is that it's an emerging or specialized interoperability standard, not a mass-market resume format. It's designed for enterprise integrations and verified-credential exchange, not for an individual to publish a file on their own domain. You don't write LER-RS by hand on a Tuesday night. A vendor implements it inside a system you'll never see.

That's the recurring theme across the official standards. They're real, they're rigorous, and they're aimed at systems integrators. None of them gives a regular person a single file they own, control, and can put at a URL. Which brings us to the last one.

cv.json: web-native and hiring-aware

cv.json is the open standard built by FreeCV for the way hiring is actually moving: AI recruiters and ATS reading structured career data straight off the web. It's open, MIT-licensed, and the spec lives at github.com/freecvorg/cv-json. The current version is 1.2. The whole thing is one JSON file at a stable URL, for example livelink.cv/ashley/cv.json.

The fields will look familiar if you've read this far: basics, work, education, skills, projects, languages, certificates, plus two that the older formats don't have. There's 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 five-line file is valid and a complete career history is valid too.

{
  "meta": { "version": "1.2", "canonical": "https://livelink.cv/ashley/cv.json" },
  "basics": { "name": "Ashley Carter", "label": "Product Designer" },
  "availability": {
    "openToWork": true,
    "roles": ["Senior Product Designer", "Design Lead"],
    "workType": ["remote", "hybrid"],
    "visa": "EU citizen, no sponsorship needed"
  },
  "work": [
    {
      "name": "Northwind Studio",
      "position": "Senior Product Designer",
      "startDate": "2022-03",
      "endDate": "2025-01",
      "highlights": ["Led the onboarding redesign", "Owned the design system"]
    }
  ]
}

Two design choices matter most. First, it's field-compatible with JSON Resume, so the basics / work / education / skills shape carries over and you're not starting from zero if you already have a resume.json. Second, contact details are hidden by default. The file is meant to be public, so your email and phone aren't exposed unless you choose to reveal them. That's the opposite default from a PDF you email around, and it's deliberate.

How a machine finds it

This is the part the other formats skip. cv.json defines discovery so a crawler or an AI agent can find the file without you sending it. Three mechanisms, any of which works:

• A <link rel="alternate"> tag in your page head pointing at the JSON, the same pattern RSS used for years.
• A /.well-known/cv.json manifest, the standard convention for "machine-readable thing lives here."
• An X-CV-Version HTTP header, so a system can detect the version without parsing the body.

It also ships with open CORS, which sounds like a small thing and isn't. Open CORS means a browser-based AI agent or a third-party tool can fetch your cv.json directly from another origin without being blocked by the browser's security model. A PDF can't do that. A Europass profile locked inside a portal can't either.

One honest boundary, and it bears stating plainly: cv.json is designed for AI recruiters and ATS to read. That's where hiring is heading, not a claim that named vendors already parse it today. No serious standard pretends to own the future it's aiming at. cv.json is built for that direction; it doesn't fake having arrived.

How AI recruiters and ATS actually consume this stuff

Before you pick, it helps to know what's reading your resume in 2026, because the answer changed. ATS usage is mainstream in enterprise hiring. Commonly cited industry figures suggest nearly all Fortune 500 companies run an ATS, with widely reported numbers around 70% of large companies and roughly 75% of recruiters using one. Treat those as directional, because they come from secondary compilations rather than audited census data, but the direction is not in doubt.

What those systems do is the important part. A modern ATS takes your resume as an input document, parses it into structured fields, then runs matching, ranking, and summarization on the result. The widely repeated line that "75% of resumes are auto-rejected by an ATS" is not supported by the evidence. In one 2025 recruiter sample, 92% of ATS users said their system does not auto-reject based on resume content. That's a small vendor-published interview sample, not a population rate, so don't carve it in stone. But it points the right way: the early filtering is usually employer-set knockout questions, not a robot shredding your PDF.

AI changed the consumption layer on top of that. By 2025 and 2026, AI in recruiting stopped being experimental. Bullhorn, citing the 2026 GRID Industry Trends Report, says 78% of fast-growing staffing firms (those growing revenue more than 25%) have AI tools embedded in their ATS. That's a specific stat about high-growth staffing firms, not all employers, so read it narrowly. One 2026 ATS summary also reports AI adoption in HR tasks rising to 43% in 2025 from 26% in 2024, citing SHRM, which is a secondary citation worth verifying at the source.

Here's why that matters for your choice. When the layer reading your data is a parser feeding an AI matcher, the cost of giving it clean structured fields drops to almost nothing and the upside goes up. A file the parser doesn't have to reverse-engineer from a two-column PDF is strictly easier to read correctly.

Why formatting wrecks the old way

Industry sources are consistent that formatting affects parsing. Tables, text boxes, multi-column layouts, and graphics raise the risk of misreading or losing structure when a system parses a document. ResumeAdapter puts numbers on it, 23% of failures from tables, columns, and graphics, and plain DOCX as the safest format at 4% failure, but those are unverified vendor estimates without published methodology, so hold them loosely. The defensible version is simpler: visual layout is the enemy of clean parsing, and a JSON file has no visual layout to misread. There are no columns to confuse. The job title is in the field literally named position.

The five standards side by side

Reading five sections is one thing. Seeing them lined up against the same questions is faster. Here's the comparison that actually decides things: who built it, what it produces, who reads it, and whether you can publish it yourself.

• schema.org. Built by major search engines, 2011. Produces page markup (JSON-LD), not a resume file. Read by crawlers for discovery. You embed it in a page; you don't publish it as a standalone career document. No resume-adoption rate exists because it isn't a resume format.
• JSON Resume. Built by an open-source community, MIT-licensed. Produces a resume.json file plus rendered themes. Read mostly by developers and rendering tools. You can publish it, but there's no discovery convention and employer adoption is limited and unmeasured.
• Europass. Built by the European Commission. Produces a structured CV and credential profile. Read by EU education and mobility systems. Regional and institution-facing, not a global ATS interchange format.
• HR-Open LER-RS. Built by the HR-Open standards body, descended from HR-XML (1999). Produces a rigorous interoperability record with verified credentials. Read by enterprise HR systems through vendor integrations. Not something an individual hand-writes or publishes. No adoption metrics found.
• cv.json. Built by FreeCV, MIT-licensed, version 1.2. Produces one public JSON file at a stable URL. Designed for AI recruiters and ATS to read off the open web. You publish it yourself, with discovery built in, open CORS, an availability block, and contact hidden by default. JSON Resume compatible.

One pattern jumps out when you stack them like this. The official standards (Europass, HR-Open) are rigorous but locked inside institutions and vendors. The web-native ones (JSON Resume, cv.json) are publishable by a regular person. And exactly one of the publishable ones, cv.json, was designed around the discovery problem instead of treating it as an afterthought. That isn't a coincidence; it's the whole reason the format exists.

What "verified" means, and why most formats don't have it

There's a real axis hiding in this comparison that's worth naming. Some of these formats can carry credentials that were signed by an issuer, meaning a university or certifying body cryptographically vouched that the claim is true. Europass digital credentials and HR-Open LER-RS are built for that. A diploma in those formats isn't just text you typed; it can be checked back to the source.

JSON Resume, schema.org, and cv.json are self-asserted by default. You type your degree, the file records your degree, and nobody signed off. That's fine for the job each one does. cv.json is meant to be the candidate's own public file, the thing an AI agent reads first, not a sealed credential vault. If issuer-signed verification is your requirement, you want the institutional formats. If a fast, open, machine-readable summary of a career is your requirement, self-asserted is the correct tradeoff, and it's the same tradeoff every PDF resume on earth already makes.

So which one should you use?

Match the format to the job. None of these is wrong; they're aimed at different targets.

1. Marking up your personal site for search engines? Use schema.org JSON-LD. It's the right vocabulary for "tell Google who this page is about." It is not your resume's source of truth.
2. You're a developer who wants your resume in git with clean diffs and themeable rendering? JSON Resume is a joy. Just know that recruiters aren't asking for resume.json and it has no discovery or hiring-aware fields.
3. Applying through EU education or mobility programs, or carrying verified credentials? Europass earns its keep. Outside that context, most systems won't read it.
4. Building enterprise integrations or moving verified learning-and-employment records between HR systems? HR-Open LER-RS is the rigorous answer. You won't hand-write it, and it's not a file you publish yourself.
5. You want one file you own, at your own URL, that AI recruiters and ATS are built to read, with discovery, open CORS, an open-to-work block, and contact hidden by default? cv.json. It's the web-native, hiring-aware option, and it stays compatible with JSON Resume so you keep your options open.

There is no single dominant open resume-data standard in broad ATS use yet. The market is fragmented and system-specific, which is exactly why owning one clean, public, machine-readable file is a hedge that costs you nothing.

A worked example ties it together. Say you're Ashley, a product designer who's quietly open to work. You keep a resume.json in git because old habits are good habits. You add schema.org JSON-LD to your portfolio so search engines understand the page. And you publish a cv.json at your own slug with availability.openToWork set to true and your contact hidden until someone you want to hear from asks. Three formats, three jobs, zero conflict. The cv.json is the one a recruiter's AI agent can fetch on its own and read without guessing.

Common mistakes when picking a format

People don't usually pick the wrong standard. They pick the right one for the wrong reason, or they expect a format to do a job it was never built for. Here are the misreads that come up most, and the honest correction for each.

• Treating schema.org as a resume. It's page markup for crawlers, not a dated, ordered career record. If you find yourself nesting OrganizationRole objects to fake a work history, you've outgrown what schema.org is for. Use it alongside a real resume format, not instead of one.
• Assuming "official" means "widely read." Europass and HR-Open LER-RS are official and rigorous, and that's exactly why they're so easy to misjudge. Official is about who governs the spec. Widely read is about who ingests the file. There is no evidence either one functions as a broad ATS interchange standard.
• Believing the "75% auto-reject" myth. It's repeated everywhere and unsupported by the evidence. The early filter is usually employer-set knockout questions, not a robot deleting your PDF. Formatting your whole resume around defeating a rejection rule that mostly doesn't exist wastes effort you could spend on clean structure.
• Stuffing layout into a parsing pipeline. Two-column designs, text boxes, and graphics look sharp to a human and raise the misread risk for a parser. If a machine is reading first, the visual flourish is a liability, not a feature.
• Picking one format and treating the others as rivals. They aren't competing for the same slot. schema.org marks up the page, JSON Resume lives in git, cv.json is the public file an AI fetches. Running two or three at once is normal, not redundant.
• Expecting any single standard to have "won." Nobody has. The market is fragmented and system-specific in 2026. Anyone telling you one format is the universal answer is selling something. The defensible move is to own a clean public file and stay compatible.

A quick checklist for a machine-readable resume

If you've decided you want a file an AI recruiter can read off the web, here's the short version of what good looks like. Run down it once and you'll catch most of what matters.

1. One file, one stable URL. Your career data lives at a fixed address you control, like yourname.example.com/.well-known/cv.json, not scattered across PDFs in different inboxes.
2. Structured fields, not styled text. The job title sits in a field named position, dates are real startDate and endDate strings, and skills are an array. Nothing the parser has to infer from font size.
3. No layout to misread. JSON has no columns, no text boxes, no decorative graphics. The thing that breaks document parsing simply isn't present.
4. Discovery wired up. A link rel="alternate" tag, a /.well-known/ manifest, or a version header so a crawler finds the file without you mailing it.
5. Open CORS. A browser-based agent can fetch it cross-origin. If a third-party tool gets blocked by the browser security model, your file might as well be private.
6. Contact hidden by default. The file is public, so your email and phone stay off it until you choose to reveal them. Public and private aren't opposites here; they're a setting.
7. Compatible with what you already have. If your file shares the JSON Resume field shape, you keep your git workflow and lose nothing by also publishing for machines.

cv.json checks every box on that list by design, which isn't an accident. The checklist is basically a description of the problems the format set out to solve. But the checklist is the point, not the brand. If another format met all seven, it would be a fine choice too. Today, the one that does is cv.json.

The honest bottom line is that nobody has won this yet. Hiring data is still fragmented and system-specific in 2026. But the direction is obvious: machines do more of the first read, structured beats styled, and a file you control at a stable URL beats a PDF in someone's inbox. You don't have to bet the farm. You just have to publish one clean file. So pick the format that's web-native, hiring-aware, and free to make, point a link tag at it, and let the machines find you. You can build your cv.json in a few minutes, free, at freecv.org/builder, and it'll stay compatible with everything you already have.