Why PDF Font Kerning and CID-Keyed Encodings Scramble Resumes in Applicant Tracking Systems

The fate of a modern job application is sealed the moment an Applicant Tracking System (ATS) strips away the visual design to read the underlying binary text stream. This extraction step dictates whether a candidate's qualifications are mapped to a database or discarded as unreadable garbage. If the parsing pipeline cannot convert the file into structured data, human recruiters never see the resume.[1][2]

Over 98% of Fortune 500 companies rely on ATS software to collect, sort, and rank job applications. These systems operate as digital gatekeepers, using multi-stage document processing pipelines to convert free-form resumes into searchable candidate profiles. The process begins with text extraction, where the software attempts to pull raw strings from the uploaded file.

To a software engineer, an ATS is fundamentally an ingestion pipeline that strips away the user interface to extract a JSON payload of skills and experience. When a candidate uploads a PDF, the system does not read it like a human being. It relies on the document's internal architecture to identify text, a process that frequently fails due to the mechanical nature of the PDF format.[1]

The core ranking mechanism in most ATS platforms is keyword frequency analysis, which compares extracted tokens against a weighted list derived from the job requisition. Hard skills, specific certifications, and exact job titles receive the highest weighting coefficients. If the text extraction phase scrambles these critical keywords, the candidate's composite score drops to zero, triggering an automated rejection.[2]

The Illusion of the PDF Canvas

The fundamental disconnect between job seekers and ATS platforms stems from a misunderstanding of what a PDF actually is. A PDF is not a semantic text document; it is a visual coordinate system designed to ensure that a page looks identical on any screen or printer. The file format prioritizes visual fidelity over structural logic.[4]

Inside a PDF content stream, text is drawn using coordinate positioning operators, such as the Tj and TJ commands. Letters do not necessarily appear in reading order inside the binary file. A header at the top of the page might be the very last object encoded in the stream, placed there by the generator to minimize font-switching overhead.[4]

Because the order of operators has zero guaranteed relationship to visual reading order, text extraction is entirely heuristic-based. The parser must measure glyph vertical coordinates to group characters into horizontal lines, then sort text fragments from left to right. This complex reconstruction is highly vulnerable to formatting anomalies.[4]

"The PDF renders perfectly because the renderer draws glyph outlines directly—it doesn't need Unicode to draw shapes," notes a 2026 technical analysis of text extraction architectures. "But any parser trying to extract actual text is stuck." When the underlying data lacks semantic structure, the ATS parser is forced to guess the document's intent.[4]

The Kerning Trap and Word Segmentation

One of the most common causes of ATS text scrambling involves font kerning tables. Kerning fine-tunes the spacing between specific character pairs to make text look balanced, such as pulling a capital "W" and a lowercase "e" closer together. Inside font files, these adjustments are stored in large two-dimensional matrices.[4]

The PDF TJ operator implements these kerning adjustments directly in the content stream, expressing the gaps in thousandths of a text space unit. A parser reading the stream encounters an array of characters and numeric adjustments, such as [(A) 120 (W)] TJ. The software must then decide whether each numeric gap represents a kerning adjustment or a physical word boundary.[4]

The PDF Extract algorithm, a common foundational tool for text parsing, attempts to approximate character text spacing by averaging a selection of the smaller character distances within a line. It uses this average to normalize horizontal distances, centering character gaps around zero while leaving word distances larger.[4]

However, this averaging technique struggles with documents that mix high-quality typography with poor font embedding. If a resume utilizes multiple font sizes, bolding, or italics for emphasis, the kerning distances fluctuate wildly. The parser's baseline average becomes skewed, leading to unpredictable segmentation errors across different sections of the document.[4]

There is no definitive rule for distinguishing between kerning and a space character; it depends entirely on the font, the PDF generator, and the specific extraction algorithm. If the parser's threshold is too sensitive, it interprets kerning as a space, splitting a word like "Developer" into "D e v e l o p e r."[4]

Conversely, if the parser's threshold is too loose, it ignores legitimate spaces and fuses adjacent words together. An applicant might possess the exact required skills, but if the ATS extracts "SeniorSoftwareEngineer" as a single token, the keyword matching algorithm will fail to recognize it. The candidate is penalized for the document's typography.[2][4]

CID-Keyed Fonts and the ToUnicode Bridge

Beyond spacing issues, the actual encoding of the characters frequently breaks ATS parsers. Many modern PDFs utilize Character Identifier-keyed (CID-keyed) fonts, particularly when documents are exported from web-based design tools like Canva or heavily formatted word processors. These tools often subset fonts, embedding only the specific glyphs used in the document to reduce file size.[3][4]

When a font is subsetted, the PDF assigns arbitrary IDs to the glyphs rather than standard ASCII or Unicode values. The bytes inside the text string are not readable characters; they are simply index numbers pointing to a specific shape in the embedded font dictionary. To extract readable text, the parser requires a translation mechanism.[3][4]

The PDF specification provides this translation through the /ToUnicode CMap, a bridge that maps the arbitrary Character IDs back to standard Unicode strings. If the font includes a correct /ToUnicode table, the ATS parser can seamlessly convert the CID codes into searchable English words.[3][4]

However, PDF generators frequently omit or corrupt the /ToUnicode CMap during the export process. This omission is invisible to the human eye because the document still contains the correct glyph shapes for rendering. But to a machine parser, the semantic meaning of the text is completely obliterated.[3][4][5]

The Extraction Resolution Hierarchy

When an ATS text extractor encounters a character code without a /ToUnicode CMap, it follows a strict resolution hierarchy defined by the PDF specification. It first attempts to fall back to the font's encoding dictionary to obtain glyph names, hoping to infer the Unicode values from standard Adobe Glyph Lists.[3]

If the font lacks standard encoding information—which is almost always the case with subsetted CID-keyed fonts—the parser reaches the bottom of the hierarchy. It is forced to use the raw character code as the Unicode code point. This results in the extraction of raw CID escape codes, such as /i255 or (cid:38).[3][5]

"When processing PDFs that have CID-keyed fonts without ToUnicode mappings, Docling extracts garbage text instead of readable content," explains a 2026 GitHub issue detailing extraction failures. The parser pulls the raw CID codes, completely bypassing the ATS keyword frequency analysis.[5]

A 2026 study published on arXiv highlighted this exact vulnerability, noting that an extractor falling back to raw codes produces text that differs entirely from the rendered glyphs. The visual and extracted token sequences become permutations of the same character set, making the divergence invisible to any diff-based integrity check.[3]

This font-decoding split allows a document to display one set of characters while feeding a completely different string to the underlying database. While security researchers study this phenomenon for potential exploits, job seekers experience it as a catastrophic formatting bug that silently deletes their professional history.[3]

This silent failure is the primary reason highly qualified candidates receive immediate automated rejections. The applicant uploads a visually stunning resume, unaware that the ATS database has recorded their entire work history as a string of unsearchable alphanumeric variables.[1][2]

Navigating the Parsing Pipeline

Once the text is extracted, the ATS assigns a composite score ranging from 0 to 100. This score determines whether the application enters the active review pipeline or remains buried in the database. The algorithm weights recent roles and exact job title matches heavily, meaning a parsing error in the work history section is particularly devastating.[2]

Semantic matching capabilities vary significantly between platforms. Legacy systems perform strict literal matching, while modern platforms incorporate limited synonym resolution. However, no system can resolve a synonym if the underlying text has been scrambled into raw CID codes. The baseline requirement for any ATS is a clean, readable text layer.[2]

To survive the parsing pipeline, job seekers must prioritize structured data over creative design. Enterprise Applicant Tracking Systems, including Workday, Greenhouse, and iCIMS, process standard DOCX files with the highest fidelity. Word documents inherently store text as semantic strings rather than visual coordinates, bypassing the kerning and CID encoding traps entirely.[1][2]

For candidates who prefer the fixed layout of a PDF, the document must be generated from a standard word processor using system-default fonts. Fonts like Arial, Calibri, or Times New Roman are rarely subsetted into CID-keyed formats, ensuring that the text remains encoded in standard Unicode.[1]

Documents generated via LaTeX also parse exceptionally well, as the compiler enforces strict structural rules and generates high-quality PDFs with clean text layers. The LaTeX engine explicitly handles the /ToUnicode mappings, ensuring that the semantic text perfectly matches the visual output.[1]

The simplest diagnostic test for a resume is to copy the entire document and paste it into a plain text editor like Notepad. If the resulting text is scrambled, missing spaces, or replaced by arbitrary symbols, the ATS parser will suffer the exact same failure.[1]

Ultimately, the recruitment process is an exercise in database management. The resume is not a marketing brochure; it is a data payload designed to populate specific fields in an employer's system. Ensuring that the payload is machine-readable is the only way to guarantee that a human being will eventually evaluate the candidate's actual qualifications.[1][2]