What a parser extracts, and how reliably
A parser is trying to turn a document written for humans into rows in a database. Some of that is easy and some of it is genuinely hard, and the difficulty is not distributed the way you would guess. An email address is trivial — it has a distinctive shape that a pattern match finds anywhere on the page. A job title is harder, because it is just words, and the parser has to infer from position and context that this particular line is a title rather than a company name or a project. Skills are hardest of all, because they can appear anywhere and look like ordinary prose. The consequence is that the fields you would consider least important are the ones that survive most reliably, and the fields a recruiter actually filters on are the fragile ones.
| Field | Reliability | What breaks it |
|---|---|---|
| Email, phone | High | Living only in the page header region |
| Name | High | Being inside an image or a designed graphic |
| Employer names | Good | Logos instead of text; unusual abbreviations |
| Employment periods | Mixed | Inconsistent date formats; seasons instead of months |
| Job titles | Mixed | Creative titles; titles merged onto the employer line |
| Education | Good | Non-standard section headings |
| Skills | Low | Prose instead of a list; skills scattered through bullets |
| Anything in a second column | Very low | The parser reads across, not down |
The pipeline: file to text to fields
Three stages, and a different thing goes wrong at each. First the file is converted to plain text, which is where image-based and scanned documents lose everything, because there is no text to extract. Second the text is segmented — the parser looks for section boundaries, usually by recognising conventional headings, and decides which block of text is experience and which is education. Third the fields inside each segment are identified. A failure at stage one is total and obvious once you look; a failure at stage two quietly relocates half your career into the wrong section. That second kind is the dangerous one, because the record looks populated. Nothing is missing in an obvious way; it is simply filed under the wrong heading, where a search for it will not look.
Stage two is where most of the interesting damage happens, and it is why conventional headings matter so much more than they should. A parser that cannot find a heading it recognises falls back on treating the text as unstructured, and unstructured text is stored but not filtered — which means the content technically exists in the database and never appears in a search. Renaming Experience to something more expressive is therefore not a stylistic risk. It is a filing risk. The same logic explains why a parser handles a dull CV better than an inventive one. It is not rewarding conformity for its own sake — it is pattern-matching against the millions of conventional documents it was built around.
Why parsing failures are silent
Nothing in the process is designed to tell you it went wrong, because from the employer's side nothing did go wrong: a record was created and stored. There is no validation step that compares the extracted fields against the document to see whether they make sense, and no notification path back to you if they do not. You submitted, you got a confirmation, and the confirmation is honest — it confirms receipt, not comprehension. From your side the outcome is indistinguishable from having applied and not been selected, which is why almost nobody ever discovers this class of problem. The only way to find it is to look deliberately, before you apply, which is a habit almost nobody has because nothing in the process suggests there is anything to check.
See what a parser extracts from your own CV
AppCV runs the same extraction an applicant tracking system performs and shows you the output — which sections it recognised, which dates survived, what came through as unstructured text. It is the only way to see this failure mode, because nothing else reports it. Free, no card.
The layouts that break parsers
Two-column CVs are the single biggest cause of scrambled records, and they are popular precisely because they look organised to a human eye. The parser reads the underlying text in the order the file stores it, which on most two-column layouts means it alternates between columns — so a sidebar of skills gets interleaved line by line with your employment history. The resulting record is not merely incomplete, it is wrong: your job titles now have fragments of unrelated text attached to them.
- Two or more columns — the parser reads across the page instead of down each column.
- Text inside images, logos or charts — extracts as nothing whatsoever.
- Tables used for layout — cell boundaries frequently vanish, merging unrelated content.
- Text boxes and shapes — often stored outside the main text flow and skipped.
- Page headers and footers — a region a number of parsers ignore by design.
- Unusual embedded fonts — can extract as the wrong characters entirely, or as nothing.
Dates: the most corrupted field
Employment periods carry more weight than almost any other field, because recruiters filter on recency and tenure, and they are simultaneously the field parsers get wrong most often. The parser needs a start and an end for every role, and it is guessing from patterns. Anything that disturbs the pattern — a season instead of a month, a range written with an en-dash in one row and a hyphen in the next, a present role marked with a word, a year on its own where every other row has a month — increases the chance that a period is misread or dropped.
PDF or Word
A text-based PDF is the safer default. It preserves your layout, it parses well in modern systems, and it cannot be accidentally reflowed by whoever opens it. The exception that genuinely matters is a scanned or image-based PDF, which contains no text at all and extracts as an empty record — if you cannot select the words on the page with your cursor, neither can a parser. Word is fine when an employer asks for it explicitly, and some recruitment agencies do because they edit CVs before forwarding them. Send what you were asked for.
Parsing, matching and ranking are three different things
These get conflated constantly, including by tools that should know better. Parsing is extraction: turning your document into fields. Matching is comparison: measuring your text against a job advertisement's text. Ranking is ordering: deciding which candidates a recruiter sees first. They are separate stages, they fail separately, and only the first is fully observable from outside. When a tool gives you one number, ask which of the three it is actually describing — usually it is a blend, which makes it uninterpretable.
- Parsing — did the software read your document? Fully testable from your file alone.
- Matching — does your language overlap the job ad's? Testable if you supply the ad.
- Ranking — where do you sit against other applicants? Not observable from outside, ever.
How to test your own CV
There is a crude version you can do in thirty seconds with no tool at all: open your CV, select the entire document, copy it, and paste it into a plain text editor. What you see is roughly what a parser sees. If your columns have interleaved, if your name has vanished, if the dates have drifted away from the roles they belong to, you have found your problem. It is not a perfect simulation — real parsers are more capable than a clipboard — but it reliably exposes the catastrophic cases, and it costs nothing.
What the clipboard test cannot show you is the segmentation stage: whether your headings were recognised and your fields correctly assigned. For that you need something that performs the extraction and reports the fields it produced. That is what our check does, and it is worth being clear about the limit — it shows you how one parser reads your CV. Systems differ, and a document that reads cleanly here can still trip a particular employer's older software. Plain structure is what travels.
Find out what actually survived
Upload your CV and AppCV shows you the extracted fields — sections, dates, titles, employers — so you can compare them against what you wrote. It reports one parser's reading, not every employer's, and it cannot tell you whether you are the strongest applicant.
Frequently asked questions
- What is CV parsing?
- CV parsing is the process by which software reads a CV file and extracts it into structured database fields — name, contact details, employment dates, job titles, employers, education and skills — so a recruiter can search and filter applications. It runs automatically on almost every application submitted through a web form, before any human sees the document. What the recruiter later searches is the extracted record, not the file you uploaded.
- What is a CV parser?
- A CV parser is the software component that performs that extraction. It sits at the front of an applicant tracking system, converts an uploaded file to plain text, splits the text into sections by recognising conventional headings, and identifies individual fields within each section. Parsers are also sold on their own to recruitment agencies and job boards that need to index large volumes of CVs, which is why the term appears in commercial software listings as well as hiring contexts.
- Why does my CV not parse correctly?
- Most often the layout. A two-column design makes the parser read across the page and interleave your columns; text inside an image or a logo extracts as nothing; tables used for layout merge unrelated content; and anything in the page header or footer may be skipped entirely. After layout, the most common cause is inconsistent date formatting, which makes the parser mis-read employment periods. Creative section headings are the third — parsers match on conventional words.
- Does PDF or Word parse better?
- A text-based PDF is the safer default: it preserves layout and parses well in modern systems. The real distinction is not the file type but whether the file contains selectable text — a scanned or image-based PDF has none and extracts as an empty record. Test it by trying to select the words with your cursor. Send Word only when an employer or agency explicitly asks, which some do because they edit CVs before forwarding them.
- How do I know if my CV parsed?
- You will not be told, which is the core problem — a failed extraction produces a successful-looking submission. The quick self-test is to select your whole CV, copy it, and paste it into a plain text editor: what appears is roughly what a parser sees, and interleaved columns or missing details show up immediately. To see the segmentation stage — whether your headings and fields were correctly assigned — you need a tool that runs the extraction and reports the fields.
Related guides
Published 21 September 2026