Checks whether a machine can read your résumé at all, then whether it matches the posting you are about to apply to.
Checks that an applicant tracking system can read a résumé at all, then matches it against a posting. Built on the JSON Resume schema.
npm i -D @alokraj68/ats-resume Built on the JSON Resume schema, so you bring a resume.json you may already have rather than learning another format. Zero dependencies.
This is not a writing checker. plainspoken asks whether prose reads as machine-written; this asks whether a machine can parse the file. The two are deliberately separate tools.
The half that matters most reads the extracted text rather than the source, because that is what an applicant tracking system actually receives. Standalone separator elements in a contact block look perfect in the DOM and on screen, and can be dropped from a PDF text layer entirely, leaving one unsplittable string where a parser expected four fields. Only reading the extraction finds it.
What a parser needs, and the location field holding five cities that parses as one nonsense place.
A position written as Junior Dev to Developer to Lead parses as one garbled job title.
Em and en dashes anywhere in a parsed field, and non-ISO dates. Date extraction is the most fragile part of parsing.
Whether the PDF has one at all. An image-only PDF scores zero everywhere.
Whether the separators survived extraction, which is the defect that looks right everywhere except where it counts.
Measured as density rather than as a statistical outlier. On a 700-word document almost any word appearing ten times clears three sigma; real stuffing sits at 2.5% or more for one term.
Team size, hiring, retention, budget, revenue, scale, delivery speed and strategy, reported as questions rather than as defects.
Lint the source
npx @alokraj68/ats-resume lint resume.jsonLint what an ATS receives
pdftotext -layout Sam-Rivera-Resume.pdf out.txt
npx @alokraj68/ats-resume lint out.txtMatch against a posting
npx @alokraj68/ats-resume tailor resume.json posting.txtFor the source checks, yes - it uses the JSON Resume schema, which is an existing open format rather than a new one. The extracted-text checks take a plain .txt dumped from your PDF, whatever produced it.
Seventy per cent or more against a posting generally clears. Sixty to sixty-nine is marginal. Under sixty and a human is unlikely to see it. The more useful output is the gap list, because that is your interview preparation.
No. It reports what a parser cannot read and which terms from the posting are missing. What to do about a missing term is a judgement call: add it where the work actually happened, mention it once if it is weak, or leave it out and treat it as a gap.