The Parsing Edge Cases That Reject Qualified Candidates

During my time at ZipRecruiter, I sat in on a support escalation that changed how I thought about resume parsing. A hiring manager at a major healthcare company complained that they weren't receiving enough qualified candidates for a senior nursing position. When our engineering team investigated, they found 47 applications from highly qualified nurses — all sitting in the system with blank skills fields and scrambled work history.

The culprit? Every one of those 47 nurses had used the same resume template from a popular career website. The template used a two-column layout with text boxes for the sidebar content. The parser extracted the main column correctly but treated the sidebar — which contained certifications, skills, and contact information — as decorative page elements. Forty-seven qualified candidates, invisible because of a template choice.

This isn't a hypothetical scenario. It's one of dozens of parsing edge cases I've seen cause real damage to real job searches. Here are the 12 most common ones, why they happen technically, and exactly how to fix each one.

Edge Case 1: Multi-Column Layouts

Multi-column resume layouts reduce overall parsing accuracy from ~93% to ~86%, with the skills section dropping from 65% to 46% accuracy.[1]

Here's what happens technically: when a PDF or Word document uses columns, the parser must determine the reading order. Does it read straight across (left column then right column on the same line)? Or does it read the entire left column first, then the entire right column? Different parsers make different assumptions, and the wrong assumption interleaves your work history with your skills section into an incomprehensible mess.

Modern ATS platforms like Greenhouse and Lever have improved their column handling significantly. But Workday, iCIMS, and Taleo still struggle with complex column layouts, particularly when columns have unequal widths or when content wraps at different points in each column.[2]

Fix: Use a single-column layout. If you prefer a sidebar aesthetic, use indentation and section breaks instead of actual columns. Your resume can still look modern without using document columns.

Edge Case 2: Text Boxes

Text boxes are floating objects that exist outside the main document text flow. Many ATS parsers skip them entirely.[3]

In Word documents, text boxes are implemented as "shapes" — graphical objects anchored to the page, not part of the text stream. When a parser reads the document's XML structure, text box content is stored in a completely different node tree than body text. Older parsers (and some current ones) only walk the body text nodes, treating text boxes as images or decorative elements.

The nursing template I mentioned earlier used text boxes for the entire sidebar. But I've also seen text boxes used for:

• Contact information blocks at the top of the resume
• Quote callouts or highlight boxes
• Skill rating bars (the visual skill bars are images; the text labels are in text boxes)
• Section headers styled as colored banners

Fix: Never use text boxes for any content you want parsed. Type directly into the document body. If you're unsure whether a template uses text boxes, copy all text from the document (Ctrl+A, Ctrl+C) and paste it into Notepad. If any text is missing, it was in a text box.

Edge Case 3: Headers and Footers

Content placed in document headers and footers lives in a separate layer that ATS parsers typically ignore.[4]

This edge case catches more people than you'd expect. Common content placed in headers: your name and contact information. Common content placed in footers: page numbers (fine to lose), your email or phone number (not fine to lose), links to your portfolio or LinkedIn profile.

In Word's document structure, headers and footers are stored as separate sections from the body content. They exist in XML nodes called and , while body content is in . Most resume parsers only process the body node.

Fix: Place your name and contact information in the document body, not in the header area. Page numbers are fine in footers — nobody needs them for parsing. Everything else should be in the body text.

Edge Case 4: Tables Used for Layout

Tables work reliably for displaying data (comparison tables in the content) but fail when used for page layout.[5]

Many resume templates use invisible tables (with hidden borders) to create multi-column layouts. This is a holdover from early web design when tables were the primary layout mechanism. The parser encounters a table and tries to extract it as tabular data, but the content is actually sequential information forced into a grid structure.

The result: your work experience entries get concatenated in row order instead of column order. Your job title ends up in the same field as your graduation date because they happened to be in adjacent table cells.

Fix: Use tables only for actual tabular data (like a certifications table with columns for certification name, issuing body, and date). Never use tables for page layout.

Edge Case 5: Non-Standard Section Headers

Parsers identify resume sections by matching header text against a dictionary of expected headers. Creative alternatives reduce detection accuracy.[6]

The parser knows what "Experience," "Work Experience," "Professional Experience," and "Employment History" mean. It does not reliably recognize "Where I've Made My Mark," "My Professional Journey," "Career Highlights," or "Impact Story." When a section header isn't recognized, the parser treats everything below it as a continuation of the previous recognized section — or as unstructured text.

At ZipRecruiter, our parser maintained a dictionary of 200+ recognized section header variations. But even that couldn't cover every creative alternative. The safest approach is to use standard headers that every parser recognizes:

Fix: Use industry-standard section headers. Creativity belongs in your bullet points, not your section names.

Edge Case 6: Special Characters and Unicode

Accent marks, special symbols, and non-ASCII characters can cause parsing corruption ranging from garbled text to blank fields.[7]

This edge case affects international candidates disproportionately. Names with accented characters (José, Müller, Françoise) can be stored incorrectly if the ATS doesn't handle UTF-8 encoding properly. Even the word "résumé" with its accent marks is not reliably ATS-friendly — most career experts recommend writing "resume" without accents for ATS submissions.[8]

Other problematic special characters:

• Em dashes (—) vs. hyphens (-): Some parsers convert em dashes to garbled text or strip them entirely, merging adjacent words.
• Smart quotes (" ") vs. straight quotes (" "): Word processors automatically convert to smart quotes, which some parsers don't handle.
• Non-standard bullet characters (★, ◆, ✓): These may not parse as list items, causing the parser to treat each bullet point as part of a continuous paragraph.[9]
• Mathematical symbols (±, ≥, ≤): Used in technical resumes, these can corrupt adjacent text in older parsers.

Fix: Use standard hyphens instead of em dashes. Use straight quotes if possible (or don't worry — most modern ATS handle smart quotes). Use standard bullet characters (• is usually fine; hyphens are safest). For international names, ensure your document is saved with UTF-8 encoding.[10]

Edge Case 7: Inconsistent Date Formats

Mixing date formats within the same resume confuses parsers that rely on consistent patterns for date extraction.

Date parsing is one of the hardest problems in NLP. A parser might see "Jan 2020," "01/2020," "January 2020," and "2020-01" — all representing the same month. When you mix formats within one document, the parser can't establish a consistent pattern and may misparse some entries.

The most common parsing failure I saw at ZipRecruiter: "March 2019 - Present" was correctly parsed, but "3/2019 - Present" on the same resume was parsed as "March 20, 2019" — a specific date rather than a month-year range. This caused the role duration to calculate incorrectly.

Fix: Pick one date format and use it consistently throughout your resume. "Month YYYY" (e.g., "January 2020") is the safest and most universally parsed format.

Edge Case 8: Embedded Images for Text Content

Text rendered as images (logos, skill bars, graphical headers) is invisible to the parser. It looks great to humans and is completely blank to machines.[11]

This includes:

• Company logos next to employment entries — the parser can't read the company name from an image.
• Graphical skill bars — those progress bars showing "Python: 90%" are images. The parser doesn't know Python exists on your resume.
• Icon-based contact sections — a phone icon next to your number, an envelope icon next to your email. The icons are fine, but if your email address is part of the image, it's lost.
• Graphical section dividers that contain text — some templates embed section headers into decorative banner images.

Fix: Every piece of text that you want parsed must exist as actual text in the document, not as part of an image. Decorative graphics are fine — just don't embed important information in them.

Edge Case 9: PDF Export From Design Tools

PDFs exported from Canva, Figma, Adobe InDesign, and similar design tools often produce files where text elements are positioned objects rather than sequential text.[12]

In a standard Word-exported PDF, text flows sequentially — paragraph after paragraph, just like in the original document. In a design-tool PDF, each text element is an independently positioned object with absolute coordinates on the page. The parser must reconstruct the reading order from spatial position, which introduces errors whenever text elements overlap, are close together, or span columns.

I've seen design-tool PDFs where the parser extracted every word correctly — but in completely wrong order. Job titles ended up in the education section. Bullet points from one role attached to a different role. The visual layout was flawless; the parsed data was chaos.

Fix: Write your resume in Word or Google Docs and export to PDF from there. If you must use a design tool, test the exported PDF with a free ATS checker before submitting it. Some design tools (notably Canva) have added "ATS-friendly" export options — use them if available.

Edge Case 10: Multiple Roles at One Company

When you've held multiple positions at the same company, some parsers create one entry (losing your progression) while others create separate entries (losing the company continuity).

There's no universally correct way to format this because parsers disagree on how to handle it. At ZipRecruiter, we saw three common formatting approaches:

1. Nested format (Company name once, roles indented below): Works well on modern parsers (Greenhouse, Lever) but confuses older systems that expect one title per company block.
2. Separate entries (Company name repeated for each role): Most reliable for parsing but makes your resume look longer and may not show the progression clearly.
3. Combined format (All titles on one line: "Senior Engineer → Lead → Director"): Humans love this; parsers usually extract only the last title.

Fix: Use separate entries with the company name repeated. Add "(Promoted from [previous title])" in your first bullet point to show progression while keeping the format parser-friendly.

Edge Case 11: Hyperlinks in Contact Information

Hyperlinked email addresses and URLs are sometimes extracted with the link metadata intact, corrupting the plain text field.

When a parser extracts a hyperlinked email from a Word document, it might get: mailto:[email protected] instead of [email protected]. For LinkedIn URLs, it might extract the display text ("My LinkedIn") rather than the actual URL, or vice versa. Some parsers strip all hyperlink formatting successfully; others don't.

Fix: Include your LinkedIn URL and portfolio URL as plain text (e.g., "linkedin.com/in/yourname") in addition to any hyperlink. This ensures the parser captures the URL regardless of how it handles link formatting.

Edge Case 12: File Naming and Metadata

Some ATS platforms use the filename to populate candidate records. A poorly named file can cause immediate confusion.[13]

A filename like "resume_final_v3_FINAL_USE_THIS_ONE.docx" or "Document1.pdf" doesn't cause a parsing failure, but it sets a poor first impression and can cause filing issues in the ATS. Some systems display the filename in the recruiter's candidate list view.

More critically, filenames with special characters (accented letters, spaces in some systems, ampersands) can cause upload failures on older ATS platforms. The file might not even submit successfully.

Fix: Name your file "FirstName_LastName_Resume.pdf" — no spaces, no special characters, clear identification. Use underscores instead of spaces for maximum compatibility.

How to Test Your Resume for Parsing Issues

The biggest problem with parsing edge cases is that they're silent failures. You submit your resume, the ATS confirms receipt, and you never know that your skills section was blank in the recruiter's view.

The biggest problem with parsing edge cases is that they're silent failures. You submit your resume, the ATS confirms receipt, and you never know that your skills section was blank in the recruiter's view. Here's how to catch these issues before they cost you opportunities:[14]

1. The Notepad test: Copy all text from your resume (Ctrl+A, Ctrl+C) and paste into Notepad (or any plain text editor). If any content is missing, it was in a text box, header, footer, or image.
2. The read-aloud test: Read the Notepad version from top to bottom. Does the text flow in the correct order? If your skills section appears between two work experience entries, you have a column or table parsing issue.
3. Free ATS checkers: Services like Jobscan, ResumeWorded, and Resume Geni's own ATS checker parse your resume and show you exactly what the ATS sees. Use them before every application cycle.[15]
4. The 5-minute review: After submitting to a company that uses Workday or iCIMS, check the application portal. Many of these systems show you how your resume was parsed into their form fields. If the fields are wrong, you know you have a parsing issue.

Every parsing issue in this article is fixable in under 10 minutes. The resume you spent hours crafting deserves 10 minutes of testing to make sure the ATS sees what you see.

Frequently Asked Questions

Will a multi-column resume get rejected by the ATS?

Not rejected, but potentially misparsed. Multi-column layouts reduce parsing accuracy from ~93% to ~86%, with the skills section accuracy dropping most dramatically. Modern ATS platforms handle columns better than older ones, but a single-column layout is the safest choice for maximum compatibility across all systems.[1]

Are Canva resume templates ATS-friendly?

Most are not, because Canva exports text as positioned objects rather than sequential text flow. Some Canva templates now include an "ATS-friendly" export option — use it if available. Otherwise, write your resume in Word or Google Docs and export to PDF for the most reliable parsing across all ATS platforms.[12]

Can I use accent marks in my name on my resume?

Yes, but ensure your document uses UTF-8 encoding. Most modern ATS handle accented characters correctly when the document encoding is right. For filenames, avoid accent marks — use the unaccented version of your name in the filename while keeping accents in the document body.[10]

How do I know if my resume has parsing issues?

Use the Notepad test: select all text in your resume, copy, and paste into a plain text editor. If any information is missing or appears in the wrong order, you have a parsing issue. Follow up with a free ATS checker tool to see exactly how the parser interprets each field of your resume.[14]

What's the safest resume format for ATS compatibility?

A single-column .docx file created in Microsoft Word or Google Docs, with standard section headers, no text boxes, no tables for layout, and consistent "Month YYYY" date formatting. This combination achieves the highest parsing accuracy across all major ATS platforms including Workday, Taleo, Greenhouse, and iCIMS.

References

1. Jobscan — Can the ATS Read Tables and Columns on Your Resume?
2. Resumemate — Tables, Columns & Text Boxes: Do They Break ATS?
3. Resumemate — Text Boxes as Floating Objects in Document Parsing
4. Jobscan — ATS Resume Formatting Mistakes to Avoid
5. Jobscan — Tables for Layout vs. Tables for Data
6. Upskillist — ATS Parsing: Common Resume Mistakes to Avoid
7. The Interconnected — Do ATS Dream of Resume Formatting?
8. MyCVCreator — How to Spell Resume: Accents or Not?
9. Upskillist — Non-Standard Bullet Characters in ATS
10. Resumly — Optimizing Resume Formats for Global ATS Compatibility
11. Distinctive Career Services — Free ATS Test for Resume
12. Scale.jobs — Why Resume Templates Look Good but Perform Poorly in ATS
13. Resumly — Optimizing Resume File Types for Seamless Parsing
14. Distinctive Career Services — How to Test Resume Parsing
15. ResumeUp — Free Resume Parser ATS Check