The text layer, and why a scanned CV scores near zero

What a text layer actually is

A PDF can carry characters, or pixels, or both. Only the characters can be searched, copied or parsed.

When you export a document from a word processor or a CV builder, the exporter writes the characters into the file along with the fonts and positions needed to draw them. That is the text layer. Anything reading the file afterwards - a search box, a screen reader, a parser - works from those characters.

When you scan a printed page, or photograph it, or export a design as an image and wrap the image in a PDF, no characters are written. The file contains a raster picture. It renders beautifully, it prints beautifully, and it contains exactly zero words as far as any software is concerned.

There is no visual difference. A scan at a decent resolution is indistinguishable from a real export on a laptop screen, which is precisely why this failure survives all the way to the employer. The applicant has no reason to suspect anything, and the system on the other end has nothing to store.

How a good CV loses its text layer

Almost nobody chooses this. It happens as a side effect of something reasonable.

• Print, sign, scan. A signature is requested, the applicant prints the CV, signs it, scans it back. The scan replaces a perfectly good export.
• Photographing the page. The desktop machine is elsewhere, the phone is here, and a photo goes into a PDF. Same result, usually with worse contrast.
• Exporting from a design tool as an image. Some export presets flatten everything to a raster to guarantee the layout. They guarantee it to a human and destroy it for a parser.
• "Print to PDF" from a viewer that rasterises. Rare, but it exists, and it turns a clean file into a picture of itself.
• A PDF assembled from a screenshot. Most often a page of certificates or references appended to the CV, taking the whole document down with it.

A related and much commoner case is the partial text layer. The body of the CV is real text, and the header - the name, the job title, the contact line - is an image, because the design tool treated the styled block as a graphic. The file passes a casual glance and fails on the one part of the document a recruiter needs most.

What it costs, and why the cap exists

A real text layer is worth 10 points. The gate is worth far more than that, which is the point.

Thresholds from the published scoring model, version 4.5.

The asymmetry between the 10 points and the 25-point cap is the honest part. If the check simply cost its weight, a scanned CV would score somewhere in the eighties and the report would congratulate the applicant on a document that contains nothing. Capping the score and explaining why is the only result that is true.

Compare this with the reading-order gate, which caps at 69 but lets every check report normally. The difference is information. A scrambled CV has findings worth reading; a scan has exactly one finding, and printing thirteen more would be noise dressed as thoroughness. The scoring guide goes through both gates in detail.

Testing yours, in ten seconds

Three tests, any one of which is conclusive.

1. Select a word. Drag your cursor across your own name. If the highlight follows the letters, there is a text layer. If it draws a box over the whole page, there is not.
2. Search the document. Open the viewer's find box and search for your surname. No result means no text.
3. Copy and paste. Select all, copy, paste into a plain text editor. An empty paste is the answer. A paste full of text is also the fastest way to check your reading order while you are there.

The checker reports the same thing with the character count per page attached, which distinguishes a total failure from a partial one - useful when the body is fine and only the header is an image, because the select-a-word test passes on the body and hides the problem.

Fixing it properly, and the last-resort version

There is one good fix and one acceptable fallback, and they are not equivalent.

The good fix: re-export from the source

Open the original document - the word processor file, the builder project, the design file - and export to PDF again with the text intact. Every CV builder does this by default, including Appliora's. If the source is gone, retyping the CV is genuinely faster than recovering a scan, and you end up with a file you can tailor for the next advert instead of a picture you cannot edit.

The fallback: OCR, with its costs named

Optical character recognition reconstructs characters from pixels. It produces a searchable file and it introduces two new problems. The first is accuracy: OCR guesses, and it guesses hardest at accented characters, so a Polish or Czech CV frequently comes back with stripped or mangled diacritics. Appliora charges that against Accented characters (5 points), a separate check with its own damage detection - replacement characters and mojibake are treated as proof rather than as inference.

The second is layout. OCR has to guess reading order from an image, with less information than a PDF parser has, so a two-column scan comes back interleaved even when the characters are right. You end up trading one capped score for another.

Whose parser this describes

Questions people ask

How do I know whether my PDF has a text layer?

Open it and try to select a word with your cursor. If the selection highlights a rectangle over the whole page instead of the individual word, there is no text layer. A second test: use the viewer's search box to look for your own surname. If it finds nothing, there is nothing to find.

Why does a scan cap the score at 25 rather than just losing points?

Because the other checks would be measuring the absence of input rather than the quality of a CV. Bullet quality on zero bullets is not a low score, it is not a score at all. Capping the report and saying the one thing that matters is more honest than averaging thirteen meaningless numbers.

I printed my CV, signed it and scanned it back. Is that a problem?

Yes, and it is one of the commonest ways a good CV becomes unreadable. The scan is a photograph of a document. Send the original export instead. If a signature is genuinely required, sign a separate page or use a digital signature that leaves the text layer intact.

My CV has text but the name and contact details are an image. What happens?

That is a partial text layer, and Appliora scores it on a ramp rather than as a pass or a fail. Under about 100 characters per page there is effectively nothing to read; above about 800 characters per page the extraction is clearly complete; between the two the score scales. The practical damage is separate from the score: contact details inside an image are not contact details at all.

Does running OCR on a scanned CV fix it?

It makes the file assessable, which is not the same as fixing it. OCR guesses characters from pixels and it guesses accented characters worst, so a Polish or Czech CV often comes back with the diacritics mangled - which Appliora then charges against a separate check. Re-exporting from the original document is always better than recovering from a scan.