ResumeATS

ATS parsing failures by file type

Updated 26 October 2026. Parsers fail in different places depending on the container, not on the adjectives in the bullets. A PDF, a DOCX, and a .txt file can hold the same jobs and still produce three different text extracts. This page is about those containers. The ResumeATS builder produces two of them on purpose: a printable page with a text layer, and a plain-text download named resume.txt. It does not produce a DOCX.

PDF: text layer, order, and ligatures

A PDF is a drawing program that sometimes also stores characters. If you can drag the cursor across a sentence and copy it, a text layer exists. If the cursor never selects words, the page is a picture, and a parser that does not OCR it stores a blank application. Print-to-PDF from this builder is the first kind. The sheet is HTML text. Browser print writes glyphs with a character map, so the name and the section labels are selectable. That is the check the end-to-end test on this project looks for: the printed sample contains the characters Jordan Avery and the capitalised section label EXPERIENCE, which is the CSS uppercase of the heading Experience.

Selectable is not the same as “read in the order a person sees.” Multi-column PDFs often store the left column and the right column as interleaved runs, or they store a sidebar after the main story, or before it. Headers and footers are painted on every page, so a phone number in the header can be repeated once per page and a parser can treat the repeat as a second candidate. Text boxes can be stored far from the paragraph they sit next to visually. None of that happens in this builder’s sheet, because the sheet is one column and the contact line is in the body, not in a running header. The moment you upload a designed file from somewhere else, those failures are back.

Fonts add a quieter failure. Some faces replace the letters f and i with a single fi ligature. A search for the word certification can miss the word if the extract still contains the ligature and the search does not decompose it. Copy the sentence into a plain editor and look for a character that will not match a normal f. If you see one, retype the word in the builder instead of trusting the PDF extract. Do not “fix” it by pasting the same PDF into a different converter and hoping the percentages change. There is no percentage to look up. There is either a text layer you can select, or there is not.

DOCX: stories a parser can skip

A DOCX file is a zip of XML. Ordinary paragraphs in the document body are the easy part. Text inside a text box, a shape, or a floating frame is often a different story. Tables are a grid of cells, and importers differ on whether they read across a row or down a column. The header and footer live in their own parts, which is why a name that exists only in the header sometimes never reaches the candidate name field. Smart quotes, em dashes, and non-breaking spaces are legal characters that some older importers turn into question marks or split into extra tokens.

Tracked changes and comments are another trap. If you leave a deletion visible, an importer may keep the deleted text, the replacement text, or both. Accept the changes and drop comments before you send a DOCX. This site cannot open a DOCX for you. If a designed DOCX is the only copy, paste the visible text into the lint box or rebuild the roles in the form. The lint looks for pipes, tab characters, and lines with two or more runs of two spaces, and it treats those as tables. A skills grid that looked aligned in Word becomes, after a sloppy paste, a line the table row will reject. Flatten it to one fact per line before you rely on it.

Plain text, including the file this site downloads

Plain text cannot hide a column, which is why application forms ask for it. It also cannot mark a real heading except by the words on the line. The sample download makes that trade on purpose. The contact line is the email, the phone, the city, and the LinkedIn path, joined with “ | ”. That is three vertical bars. The paste lint flags a line as a table when it contains two or more bars, a tab, or two or more double-space runs. So if you paste the downloaded resume.txt back into the lint box, the table row fails on the contact line even though the builder’s own preview has no table. The download is for the employer’s paste box. It is not a second copy of the lint’s expected layout.

The heading row fails for a different reason. The first line of the file is “Jordan Avery.” It is short, it starts with a capital, and it is not in the safe heading list, so it is reported as a bad heading. The title line “Senior Marketing Operations Manager” is also a candidate. The date line “Jan 2021 – Present” is a candidate too. EXPERIENCE, EDUCATION, and SKILLS are accepted. The lint reports the first bad candidate, which is the name, and stops the explanation there. None of this means the plain-text file is unusable. It means the paste scanner is a heading detector, and a plain-text resume has several short title-case lines that are not section labels. Leave the paste box empty when you are scoring the form. Use the paste box when you are testing a file that was written with section labels, not when you are re-importing resume.txt.

Dates inside that .txt file are not the dates the lint scores. Date checks read the form fields only. You can have Jan 2021 in the boxes, a passing date row, and a completely different date string in a pasted file. If those ever disagree, the form is what the preview and the download will use the next time you export. Fix the boxes.

What to send

  1. If the form says PDF, print from the builder and confirm you can select the name in a PDF reader. Do not export a screenshot or a “print to image” path.
  2. If the form says paste or .txt, use Download .txt. Do not paste the PDF’s copy-out if the copy-out merged columns.
  3. If the form says DOCX and you only have this site, paste the .txt into the form’s text fields, or rebuild a simple document elsewhere from that text. Do not wrap the text in a table to make it look like a template.
  4. After any conversion, read the extract yourself. Look for a missing phone, a heading that became a sentence, or a skill that turned into a ligature. The parse guide is the sequence. The formatting checklist is the list of shapes that cause the extract to go wrong.

No file type is universally safe. A one-column text layer is safer than a designed two-column PDF. A .txt is safer than a text box buried in a DOCX. The builder’s job is to give you those two safer containers from the same form, and to show the lint failures when a paste still looks like a table, a glyph, or an unknown heading.

Related reading: plain text for online forms and how an ATS parses a resume. Export from the ResumeATS builder.

Questions

Why does pasting resume.txt into the lint box fail?

The contact line joins four fields with vertical bars, and two or more bars are treated as a table. The name line is also a short title-case line, so the heading check reports “Jordan Avery” as a heading it does not recognise. The download is meant for an employer paste box, not for the lint box.

Does the builder make a DOCX?

No. It makes a browser print, which is a PDF with a text layer when you choose Save as PDF, and a plain-text file named resume.txt. A DOCX has to be assembled elsewhere from that text if a form refuses both.

How do I tell a scanned PDF from a text PDF?

Try to select a sentence. If the selection grabs letters, a text layer exists. If the page will not select, the parser may store nothing unless it OCRs the image. Rebuild the resume in the builder instead of re-saving the picture.