Is a resume parser an automated employment decision tool?
Not on its own. An automated employment decision tool scores, ranks, or screens people. A parser reads a document and returns what it says. ResumeJSON does the second and has no ability to do the first — there is no score, no rank and no fit judgement anywhere in the response, because there is no such field in the schema.
This page describes what this software does and does not do. It is not legal advice, and it cannot tell you whether your system is in scope — see what still sits with you.
What an automated employment decision tool is
The term is New York City's. Local Law 144 defines an automated employment decision tool — an AEDT — as a computational process that issues a simplified output: a score, a classification, or a ranking, used to substantially assist or replace discretionary decision-making about hiring or promotion. An employer using one owes an annual independent bias audit, a published summary of its results, and notice to candidates.
The EU AI Act draws its line in the same place and calls the result high-risk: Annex III lists AI used to recruit or select people, and in particular to filter applications and evaluate candidates. Both instruments regulate the thing that reaches a conclusion about a person.
Neither regulates reading. Optical character recognition, text extraction and field parsing produce no simplified output about anybody — they restate what the document already said, in a shape a program can index.
Where the line sits
The distinction is not a matter of degree, and it is visible in the response body. Here is what this API produces and what it has no mechanism to produce.
| Extraction — what this API does | Decision — what it does not |
|---|---|
Reads company, title, start_date off the page | Judges whether the role is relevant |
Returns skills as the CV lists them | Matches them against a job description |
Normalises "Sept 2019" to "2019-09" | Infers seniority from the dates |
Returns null for anything the CV does not state | Fills the gap with a guess |
Sums stated durations into total_years_experience | Reads that sum as a qualification |
| Hands you the fields | Ranks, scores, shortlists or rejects |
The right-hand column is not a list of features held back. The field reference is the whole response, and it contains no score field, no rating, no match percentage and no recommendation. total_years_experience is the only computed number on the page, and it is arithmetic: the stated durations of the roles already in work, added up in our own code rather than taken from the model, so that it is a sum and never an opinion.
What this service keeps
Three facts about the data path, each of which you can check against the behaviour rather than take on trust.
- There is no database. Not "we delete after 30 days" — there is no store to delete from. A parse is one request: the document arrives, the JSON goes back, and nothing about it outlives the response.
- The usage counters carry no document. What is recorded per call is which endpoint, what the outcome was, how long it took, and which of three broad classes the caller falls into. No IP address, no filename, no text from the CV.
- The parser never invents. A field the resume does not state comes back
null. Nothing is inferred from an area code, a name or a school. This is a correctness rule first, but it matters here too: an inferred attribute is exactly the kind of derived personal data a candidate never supplied.
What does leave. The document is sent to a third-party model provider to be read — that is how the parsing happens, and a buyer with a data-processing agreement to fill in needs to know a sub-processor exists. What we can tell you is what we retain, which is nothing, and that every call carries a data-retention policy excluding any endpoint permitted to keep or train on what is sent. If no endpoint meets that policy the parse is refused rather than handed to one that would.
What still sits with you
This is the part a compliance page usually leaves out, and it is the part that decides your answer.
A neutral component does not make a neutral system. If you take these fields and score them, rank candidates by them, or filter a pipeline on them, the thing you have built may well be an AEDT — and the obligations attach to your system and to you as the employer or agency, not to the parser inside it. Swapping in an extraction-only parser removes one question; it does not answer the one about what happens next.
Data-protection duties are separate and they do apply. A CV is personal data the moment you hold it. Lawful basis, retention, candidate notice and access requests are yours whether the parsing is done by us, by another vendor, or by hand. What this service can do is not add a second copy of that data to the world.
The honest summary: using ResumeJSON does not put you in scope of the AEDT rules, and it does not take you out of scope either. It keeps the extraction step out of the argument, so the assessment is about the decisions you actually make.
Questions
Is resume parsing regulated under NYC Local Law 144?
Parsing on its own is not the regulated activity. Local Law 144 attaches to a tool producing a simplified output — a score, a classification or a ranking — that substantially assists or replaces a discretionary hiring decision. Extracting the fields a CV already states produces no such output. If a system downstream of the parser scores or ranks candidates, that system is what gets assessed.
Does the EU AI Act make a resume parser high-risk?
Annex III makes AI used to recruit or select people high-risk, naming the filtering of applications and the evaluation of candidates. A parser that returns the document's own contents does neither. The classification follows what the system is used for, so the same answer holds: the evaluation step is the one that carries the obligations.
Do you store the resumes I send?
No. There is no database in this service — a parse is a single request and nothing about it outlives the response. The per-call usage counters record the endpoint, the outcome and the duration, and carry no IP address, no filename and no text from the document.
Is the document sent anywhere else?
Yes — it is sent to a third-party model provider to be read, which is how the parsing is done. That provider is a sub-processor for the purposes of your data-processing agreement. We retain nothing ourselves, and every call carries a data-retention policy excluding any endpoint permitted to keep or train on the document; if no endpoint meets it, the parse is refused rather than sent to one that would.
Does the parser infer anything about the candidate?
No. A field the resume does not state comes back null rather than guessed. Nothing is inferred from an area code, a name, a photograph or an institution. The one computed value, total_years_experience, is the sum of the stated durations of the roles in the response, calculated in our code rather than taken from the model.
Can I see exactly what a parse returns before deciding?
Yes, without an account or a key: the free resume parser runs your own CV through this same endpoint and shows you the whole response. Reading the actual output is a better basis for a compliance review than any claim on this page.
Build on extraction only
One endpoint, a typed resume back, and no judgement about anybody in it.