What I learned about document parsers by building an ATS cover letter checker

TL;DR

• Most ATS parsers flatten a document to plain text, then map sections to fields. Anything unmappable is dropped.
• Document headers and footers are skipped by many parsers, so contact details placed there vanish.
• .docx parses most reliably when the advert does not specify a format. PDFs exported from design tools frequently fail text extraction entirely.

---

I have spent an unreasonable amount of time reading how applicant tracking systems extract text, because I am building CVPilot and the parsing layer is where most of the damage happens. The interesting part is that almost none of the failures are about writing quality.

They are structural. Two column layouts get spliced left to right into one scrambled paragraph. Text boxes are invisible to the parser. Tables used for layout detach dates from the roles they belong to.

The header problem

This one catches almost everyone. Put your name, phone number and email in a Word header and a large number of parsers will skip the region entirely. The candidate arrives in the system with no contact details attached, and a human never finds out why.

Keep contact details in the body of the document, on the first few lines.

File format reliability

.docx is the safest default when the advert does not specify. A PDF exported from Word is usually fine. A PDF exported from a design tool often embeds text in a way that never extracts.

Keyword matching has moved on

Modern systems apply semantic matching, so repeating a phrase eight times no longer helps and increasingly hurts. Use the employer's exact terms for skills and job titles once each, then spend the remaining words on evidence.

Read the full breakdown, including the UK template: https://cvpilot.pro/blog/ats-friendly-cover-letter-2026-uk-guide?utm_source=devto&utm_medium=organic&utm_campaign=ats-cover-letter

If you have written a parser for user-supplied documents, what was the worst input you had to handle?