We exported a PDF from the builder and fed it back to the checker

A PDF looks like a document and is stored as drawing instructions. What a parser gets back is a question with a measurable answer, so we measured it.

ConxfolioPublished 2026-09-12

— the bullets are the first thing the page loses.

A PDF is not a document with text in it. It is a set of instructions for drawing glyphs at coordinates, and the text layer is a courtesy the exporter may or may not have left behind. Every claim about what an applicant tracking system reads depends on that layer, and almost nobody checks it.

So we did the round trip: built a résumé, exported the PDF this product renders, and put that exact file back into the ATS résumé checker.

How the file was read

The text layer is pulled out in the browser by a PDF engine bundled with the page, before anything is sent anywhere. Where a page has no text layer at all, optical character recognition runs over the image instead, and the reading line reports how many pages needed it. Our export needed none: one page, read by five specialists, and the source step showed the file name with 159 words read beside it.

What came back

Against a pasted source of 162 words, that is a near-complete recovery: every heading, both employers, both date ranges, all nine skills and all seven achievement sentences, in the right order. The line has extra clauses precisely because the reader found roles and skills to count.

The one number that moved

The round trip published 94 where the pasted text published 97. Parseability and completeness were identical. Inside content, one rule moved: evidence depth, from 25 points to 18, with the report stating the reason in its own words on the fix row: 4 experience achievement lines were detected.

Why four and not seven

The depth rule counts a line under Experience as an achievement when it either starts with a bullet mark or starts with a recognised action verb. The pasted source had seven lines each beginning with a hyphen, so all seven counted. The rendered page draws its bullets as layout rather than as characters, so the text layer has none, and only the lines that happen to open with a recognised verb survived the count: reduced, led, built, cut. Rebuilt, wrote and mentored did not. That is a real and checkable behaviour of the rule, and the practical lesson is the one every résumé guide gives for a different reason: start the line with the verb.

What this says about your own file

Run the file you actually send. A résumé that pastes at 400 words and uploads at 90 has a text layer problem, and no amount of rewriting will move the score until the export changes. The counts are printed for exactly this, as described in what the checker read, and the layouts most likely to survive the trip are the ones marked in what ATS-safe means on a design.

What a scanned page does to the same test

A PDF that was printed and photographed has no text layer at all. The reader falls back to optical character recognition in the browser, and the reading line says so by counting the pages that needed it. That is a much worse starting position: recognition is good rather than perfect, and its errors land in exactly the places that hurt, which is proper nouns, job titles and figures.

Where a scan is the only copy of a résumé, the repair is to rebuild the document rather than to improve the scan. Import it, let the reader do what it can, correct the fields on the review, and export a fresh PDF whose text layer is real. The round trip above is then available as a check, and it takes a minute.

What we are not claiming

That our reading is an employer's reading. It is one parser, ours, and a different one will differ at the edges. What the round trip does establish is that a document exported from this product still contains its own text when it arrives, which is the minimum a résumé builder owes you and is not universal. The other export, the Word file, never goes near a server at all: we measured that too.