How Resume File Format Affects ATS Parsing

When a resume enters an applicant tracking system, the first thing the system does is not read the content — it attempts to extract the text. That extraction step is governed almost entirely by the file format submitted. A format the system can parse cleanly produces a structured data record. A format it cannot produces a partial record, a blank record, or an error state that a recruiter may never see flagged.

This piece covers the mechanics of that extraction layer: what different file formats do inside an ATS, which structural features cause parsing to succeed or fail, and what the resulting record actually contains — or omits — when the process completes. The content of the resume matters only after the format has allowed the text to move.

How File Format Determines What the ATS Actually Receives

An applicant tracking system receives a file and passes it through a text-extraction engine before any other processing occurs. The engine's job is to convert the file into a plain string of characters that the system can then segment into fields — name, contact information, work history, education, skills. The outcome of that conversion depends on how the file encodes its content.

A plain-text file (.txt) is the simplest case: the file contains only characters, with no embedded formatting instructions. Extraction is nearly lossless. Every word the applicant typed is available to the parser in the order it was typed. The tradeoff is that plain text carries no visual structure, so the parser must infer section boundaries from line breaks and keyword cues like "Experience" or "Education."

A word-processing format (.docx) stores text inside a compressed archive of XML files. Most modern ATS extraction engines are built to read this XML directly, which means the text is generally recoverable in full. However, content placed inside text boxes, headers, footers, or certain table cells is stored in separate XML nodes that some engines do not traverse. That content — often contact information placed in a header — may be silently omitted from the extracted record.

A portable document format (.pdf) introduces the most variation. A PDF created by saving or exporting from a word processor embeds the text as a selectable layer; extraction engines can read this layer much as they read .docx XML. A PDF created by scanning a paper document or by printing to PDF from certain design applications stores the page as an image. There is no text layer. Unless the ATS includes optical character recognition (OCR), the extracted record is empty. Even when OCR is present, it introduces character-level errors — a lowercase "l" misread as the number "1," for example — that corrupt keyword matching downstream.

Understanding how the ATS handles resume structure makes clear why the file format decision precedes every other formatting choice. Column layouts, decorative dividers, and icon-based contact fields all depend on the format behaving predictably inside the extraction engine — and that behavior is not uniform across systems.

Less common formats — rich text (.rtf), OpenDocument (.odt), and HTML files — are handled inconsistently. Some ATS platforms parse them without issue; others convert them to plain text with unpredictable results; others reject them outright and return the file to the applicant. When a system rejects a file silently, the application may appear submitted from the applicant's side while generating no record on the employer's side.

Roles and Systems Involved in Format Processing

The applicant tracking system. The ATS is the primary actor at this stage. It receives the file, routes it to an extraction engine, and attempts to populate a structured candidate record. Different ATS platforms use different extraction libraries, which is why the same file can parse cleanly in one system and fail in another. The ATS does not notify applicants of parsing failures in most implementations.

The extraction engine. This is a software component — sometimes built into the ATS, sometimes a third-party library — that handles the actual file-to-text conversion. Its capabilities determine which PDF types are readable, whether table content is captured, and whether headers and footers are included. The extraction engine operates before any human reviewer is involved.

The job board or career site. Many applications are submitted through a job board or a company's own careers portal, which may impose its own file-type restrictions before the file reaches the ATS. A portal that accepts only .docx files eliminates PDF parsing variability entirely at the point of submission. A portal with no restrictions passes the format decision entirely to the applicant.

The recruiter or HR coordinator. A human reviewer enters the process only after the ATS has produced a candidate record. If the record is incomplete due to a parsing failure, the recruiter sees a sparse profile — or, in some systems, no profile at all. Whether a recruiter investigates a blank field or moves on depends on workflow, volume, and whether the system flags the anomaly. At high application volumes, sparse records are typically not investigated. This is the point where a format failure becomes a practical elimination, separate from any evaluation of the resume's content.

The keyword matching layer. Once text is extracted, the ATS compares it against the job requisition to produce a relevance signal. What that match score actually measures is term frequency and field placement — but it can only measure what the extraction engine successfully recovered. A resume with strong keyword density in a section that failed to parse contributes nothing to the match calculation.

Where Format Choices Produce Unexpected Parsing Results

Headers and footers containing contact information. Placing a name, phone number, or email address in the header of a .docx file is visually clean but structurally problematic. Many extraction engines skip the header XML node entirely. The resulting record may contain work history and education but no contact information — making the candidate unreachable even if the content scores well.

Multi-column layouts. A two-column resume is common in visually styled templates. When an extraction engine reads a .docx or PDF with columns, it may read across columns left-to-right rather than down each column independently. The extracted text then reads as a scrambled interleaving of two separate content streams. A job title from the left column may appear concatenated with a skill from the right column, producing strings that match no keyword in the job description.

Tables used for visual alignment. Tables are frequently used to align dates with job titles or to create side-by-side skill lists. Depending on how the ATS traverses table cells, this content may be extracted in cell order (left to right, top to bottom) rather than in the reading order a human would follow. The result can break the logical relationship between a job title and its associated dates or responsibilities.

Embedded graphics and icons. Contact information displayed as icon-plus-text (a phone icon next to a number, an envelope icon next to an email) is a design convention that extraction engines ignore. The icon is an image object; the engine extracts only the adjacent text. If the text is formatted as part of the image — as happens in some design-tool exports — the contact detail is lost entirely.

Font substitution in PDFs. A PDF that embeds non-standard fonts may render correctly on screen while storing characters in a private encoding. When the extraction engine reads the character codes, it retrieves the encoding values rather than the visible glyphs. The extracted text contains strings of symbols or incorrect characters. This failure mode is invisible to the applicant, who sees the PDF display correctly in any viewer.

The downstream effect of these failures connects directly to how an ATS parses the full resume structure — field segmentation, keyword extraction, and match scoring all depend on the text arriving intact and in coherent order.

What the ATS Candidate Record Shows — and What It Omits

After extraction, the ATS populates a structured candidate record. This record is what a recruiter views and what the keyword matching engine reads. It is not the resume file itself — it is a database representation of what the extraction engine recovered.

A clean parse produces a record with populated fields: full name, contact details, a chronological work history with employer names, titles, and dates, an education section, and a skills or keyword block. The recruiter's view of this record may look similar to the original resume layout, but it is drawn from the database fields, not the file.

A partial parse produces a record with some fields populated and others blank or truncated. A recruiter viewing this record sees gaps — a missing phone number, a work history that starts mid-sentence, an education section that contains only a graduation year with no institution name. These gaps look like omissions by the applicant rather than extraction failures. There is typically no indicator in the record that a parsing error occurred.

A failed parse — most common with image-based PDFs submitted to systems without OCR — produces a record with a file attachment but no populated fields. The applicant's name may appear (pulled from the filename or from the application form fields filled out separately), but the resume content is absent. The match score for such a record is typically zero or null, since there is no text to match against the job description. Resume keywords, no matter how well chosen, produce no signal when the text never reached the matching layer — which is precisely what resume keywords actually match against: the extracted text string, not the file.

What the record does not show is the visual design of the resume. Column layouts, typography, color, and whitespace exist only in the file. The recruiter's ATS view is a structured data form. Formatting choices that serve visual appeal have no representation in the record and no effect on match scoring — their only function is in the extraction step, where they can either facilitate or obstruct text recovery.

File format sits at the entry point of the entire ATS process — before keyword matching, before recruiter review, before any evaluation of qualifications. The extraction step is automated, silent, and largely invisible to the applicant, which means its failures are also invisible until a record is either absent or incomplete in the system.

Note: This explains how hiring works as a system. It is not career coaching or legal advice, and it is not a substitute for a career professional or employment attorney. Check the cited sources for current labor-market and employment-law data.