Why ATS Discards Your Tables, Text Boxes, and Headers

Imagine a hiring manager at a mid-size company. They open their ATS, search for candidates who applied to the senior PM role, filter by email domain to find a specific applicant their colleague mentioned. Zero results.

The candidate applied. The portal confirmed it. But the ATS has no record of their name or email because both lived inside a Word header, a separate XML layer that most parsers skip entirely. To the database, the person is a ghost. No callback. No explanation.

This isn't a freak edge case. It happens at scale, across Workday, Taleo, and every major ATS platform. And it happens because of a small number of formatting choices that look completely fine on screen.

5 elements that break ATS parsers:

1. Tables -- parser reads horizontally across the page as a linear text stream, merging adjacent cells into unclassifiable strings
2. Text boxes -- treated as floating objects in Word's XML, categorized separately from the main document, often skipped entirely
3. Headers and footers -- exist in a separate XML section; parsers skip them to avoid reading page numbers as content
4. Multi-column layouts -- same linear-reading problem as tables; columns get merged left-to-right instead of top-to-bottom
5. Icons and graphics -- disrupt text scanning and embed as non-text Unicode garbage when extracted

Now let's look at why each one fails technically, because understanding the mechanism is what stops you from recreating the problem in a "simpler" template.

Tables: The Linear Reading Problem

ATS parsers don't see a grid. They see a stream of text, read left to right, top to bottom, across the entire page. When your resume has a table, the parser reads across each row, pulling content from every cell in sequence.

A skills table that looks like this on screen:

| Project Manager | JavaScript, React | 5 years |

...extracts as: "Project Manager JavaScript, React 5 years" -- one continuous, unstructured string. According to Jobscan (note: Jobscan sells ATS optimization tools, so weigh that accordingly), ATS systems read across rows rather than down columns, producing "word salad" where skills and job titles get merged into strings the system can't classify.

Separately tested by Wild and Free Tools: text-layer scrambling means the extracted text doesn't resemble what a human reads. And ATS Hiring's analysis notes that even modern systems that handle simple single-row tables correctly still merge cells unexpectedly across different vendors -- so a table that works in Greenhouse might break in Taleo.

The fix is not "use simpler tables." The fix is no tables.

Text Boxes: The Floating Object Problem

In Word's file format (DOCX is a ZIP archive of XML files), text boxes are stored as floating objects, separate from the main document body. They're in the same layer as annotations and watermarks, not the same layer as your paragraphs.

Upskillist's breakdown of ATS parsing mistakes puts it plainly: text boxes are treated as graphics, not text. Woberry's resume guide categorizes them as ATS killers for the same reason -- the parser never reaches that layer.

This is a common trap in resume templates downloaded from Etsy or Canva. The design looks structured and clean. Sections have crisp borders. The formatting feels professional. But if those sections are text boxes, the content inside them may as well not exist from the parser's perspective.

Headers and Footers: The Contact Info Trap

This is the one that hurts the most because the failure is completely invisible.

Word headers and footers exist in a separate XML section of the document. Parsers are specifically configured to skip them. The reason is sensible from an engineering standpoint: page numbers, "Confidential," and document titles all live in headers and footers, and you don't want those appearing in a candidate's name field.

The problem is that many resume templates, especially "clean" or "modern" ones, put the candidate's name, email, and phone number in the header for visual alignment. Centered at the top, large font, looks great. Extracts as nothing.

A LinkedIn post from a recruitment engineer with direct access to Workday and Taleo configuration confirmed both platforms are set to skip headers and footers entirely. The stated reason: to avoid ingesting page numbers as content. The side effect: contact info in the header returns Name=NULL, Email=NULL in the parsed record.

A recruiter searching by email address finds no match. An automated filter on "has valid email" removes the application. The candidate never hears back and assumes they were underqualified.

An independent Reddit user who spent 8 months testing ATS behavior (no vendor affiliation) reached the same conclusion: "most ATS straight up ignore header and footer content."

Linkifyi's guide includes a quick verification test: press Ctrl+A, copy everything, paste into Notepad. If your name and contact info don't appear in the pasted text, a plain-text ATS parser won't see them either.

This is worth doing right now if you have an active resume you're submitting anywhere.

Graphics and Icons

Reddit's reverse-engineering thread on ATS parsing documents what happens when icon fonts are used for section markers or skills ratings: the symbols extract as non-text Unicode characters, which create noise in the parsed output and can cause errors in downstream processing. A "star rating" for your Python skills doesn't extract as a number. It extracts as a symbol that the parser can't interpret, and can corrupt the text around it.

Images of logos, headshots, and decorative lines have the same problem. They're ignored at best, disruptive at worst.

The Self-Test

Paste your resume into a plain text editor (Notepad on Windows, TextEdit in plain-text mode on Mac). What you see is approximately what an ATS parser extracts.

Specifically check:

• Is your name at the top?
• Is your email and phone number there?
• Do your job titles and bullet points read in the right order?
• Is there any scrambled or merged text?

This test, documented by Linkifyi, catches header/footer issues, text box losses, and table scrambling in one pass.

The Fix

Three rules that eliminate all of the above:

1. Single-column layout, body text only. No tables, no text boxes, no columns. Standard paragraphs and bullet points.
2. Contact info in the document body. Your name, email, phone, and LinkedIn URL go in the first few lines of the actual document, not inside a Word header.
3. No icons, graphics, or decorative elements. If it can't be selected as text with Ctrl+A, remove it.

If you're working from an existing resume that might have these issues and want to check what keyword gaps remain after fixing the format, BulkResumes runs your cleaned resume against specific job descriptions and flags what's missing. But step one is always getting the format right so the parser can actually read the thing.

For more on how parsers work at the system level, see How ATS Actually Works. For what "ATS-friendly" actually means as a standard, What Is an ATS-Friendly Resume covers it. And if you're using a two-column layout specifically, Does ATS Parse Columns goes deeper on that failure mode.

Short Version

• ATS parsers read documents as linear text streams, not as grids or layers
• Tables merge adjacent cells into unclassifiable strings
• Text boxes are floating objects in Word's XML and are skipped by most parsers
• Headers and footers are in a separate XML section; Workday and Taleo skip them entirely
• Contact info in a header returns Name=NULL, Email=NULL in the parsed record
• Graphics and icon fonts extract as Unicode garbage
• Self-test: paste your resume into Notepad; if your name and email aren't there, neither is the ATS's copy
• Fix: single-column layout, all contact info in the document body, no graphics