HR-XML resume: what it is, and when JSON is less work

Published 22 September 2026

HR-XML resume: what the format is, who still emits it, and how to get JSON

An HR-XML resume is a candidate record written in the XML vocabulary published by the HR Open Standards Consortium — a Resume document with nested elements for contact details, employment history, education and competencies, designed so that two HR systems can exchange a candidate without agreeing on anything else first. If you have landed here because a vendor just handed you a wall of angle brackets, the practical answer is short: HR-XML is a standard interchange format, not a convenient application format, and most teams parse it once at the edge and store something flatter.

This article is for the developer who has to decide. It covers what the standard is and who runs it, which resume parsers still return HR-XML as of September 2026, when HR-XML is genuinely the right call, and when a typed JSON schema is less work for the same data. We build ResumeJSON, a resume parsing API that returns JSON, so read this as written by an interested party. Every claim about somebody else's product below was read off that vendor's own pages as of September 2026, and their pages are theirs to change.

What HR-XML actually is

HR-XML is the older name for the specification suite maintained by the HR Open Standards Consortium. Their own site describes the organisation as founded in 1999 and "the only independent, non-profit, volunteer-led organization dedicated to the development and promotion of a standard suite of specifications to enable human resource related data exchanges", and states plainly that "our voluntary consensus standards are free."

Two things follow that surprise people:

• The standards are free to download, not licensed per seat. The consortium's downloads page is headed "HR-JSON and HR-XML standards libraries", and the published versions are available for free public download after registering a free Community account. Work-in-progress drafts and the working repositories are the part reserved for members.
• There is a JSON side too. The suite is no longer XML-only — the same body publishes HR-JSON libraries alongside the HR-XML ones. So "HR-XML" in a vendor's feature list usually means the older XML serialisation of a vocabulary that now also exists in JSON, and that distinction matters when somebody tells you a standard requires XML. It does not.

For a resume specifically, the elements you will meet are a candidate profile (person, contact methods), employment history as repeated positions with employer, title and dates, education as repeated institutions and degrees, and competencies — skills, usually with some proficiency or last-used metadata attached.

Who still returns HR-XML, as of September 2026

Not every parser does, and the split is sharper than the category's marketing suggests.

HireAbility is the clearest HR-XML case still being sold directly. Its ALEX parser page states that "ALEX processes resumes and CVs in real-time and results return to you in the form of HR-XML or JSON data string", and its integration page publishes both sides openly: under HR-XML Output Schemas a Resume HRXML Schema and a Job Order HRXML Schema, each in an XML and a TXT version, and under JSON Output Schemas the equivalent Resume and Job Order JSON schemas. The same page lists ready-made code samples for VB.NET, C#, PHP, Java, Ruby on Rails, Python and plain HTML POST, and invites you to ask for one in a language they have not written yet. If HR-XML is a hard requirement of the system you are feeding, this is a vendor built around it.

Textkernel has moved the other way. Their resume parser page answers the output question in their own words — "Our REST API returns results in the JSON format, as per our documentation's schema. Please note that we don't support excel or csv output" — and offers normalisation to a specific standard as a separate capability rather than as the output serialisation. So a search for "Textkernel HR-XML" that finds an old integration guide is finding history, not the current API contract.

The general shape: HR-XML survives strongly in enterprise ATS and HRIS integrations, where the format was chosen years ago by whichever system sits downstream, and it is largely absent from the self-serve parsing APIs written in the last few years, which return JSON because their callers are writing JavaScript, Python or Go against an HTTP endpoint.

When HR-XML is the right call

Stay with an HR-XML parser, and do not let anybody talk you out of it, when:

• Something downstream demands it. An HRIS, a payroll platform, a government or consortium data exchange, or a client's ATS that documents an HR-XML ingest. If the receiving system's contract is HR-XML, receiving HR-XML from your parser means zero mapping code you have to own.
• You need a vocabulary you did not invent. Two parties exchanging candidates need a shared meaning for "competency" and "employment period". A standard gives you that argument pre-settled; a vendor's proprietary JSON shape does not.
• Your data has to outlive your vendor. A standard's schema is published and versioned by a body that is not your supplier, which is a real consideration if you are storing records for years.

When a typed JSON schema is less work

The opposite case is the one most application developers are actually in: you are adding CV upload to a job board, an applicant tracking system or a matching tool, and the "integration" is your own database. There, HR-XML costs you three things in a row.

1. Parsing. You need an XML parser and a namespace-aware traversal to get at values that arrive as attributes on some elements and as text nodes on others.
2. Optionality. Standards are permissive by design, because they must cover everybody. Most elements are optional and repeatable, so every field you read is a maybe an array, maybe absent case in your code, and a shape that admits anything cannot be typed usefully at the boundary.
3. Mapping. You write and maintain the translation from the standard's vocabulary into your own tables — and that mapping is where the quiet bugs live, because it is the code nobody re-reads.

A typed JSON schema skips all three when you have no third party to agree with. What we return is one fixed shape — basics, work, education, skills, certifications, languages — that deserialises straight into a struct or an interface, with a published field reference and an OpenAPI document so your types can be generated rather than hand-written.

The honest trade is this: a standard buys you interoperability you are not using, at the cost of mapping you have to write. If there is no second party, you are paying for the first and receiving only the second.

Our published plans, for comparison

Because the quote-only vendors in this category will not tell you this before a call:

Sold and metered through RapidAPI. What we do not do, stated here rather than discovered later: no HR-XML output, no schema customisation and no job-posting parsing. If HR-XML is on your requirements list, the section above names the vendor to talk to, and that is the right outcome of reading this page.

How to decide in ten minutes

1. Ask what consumes the output. Your own database, or somebody else's system? Only the second answer makes the format a requirement.
2. If it is somebody else's, get their contract in writing — which schema, which version. "HR-XML" alone is not a specification; the consortium publishes families of documents, and the receiving system implements one.
3. If it is your own, write the struct you want first, then see which parser gets you closest to it. That question decides more than any feature table.
4. Try both on your own CVs. HireAbility's trial is 30 parses valid for 30 days; ours is 100 parses a month for nothing. Ten real documents tell you more than a comparison page, including this one.

If you are still mapping the category, CV parser API covers the options and what each returns, and open source resume parser covers the case where you would run one yourself instead.