Can ATS Read Tables, Columns, Icons, And Design Elements? (2026 Guide)

How ATS extraction actually works

ATS systems open your file with a parsing engine that walks the document in reading order and tries to assign chunks of text to known fields. Visual layout is not what the parser sees — it sees a stream of text, fonts, and absolute positions.

When that stream is linear and labeled, parsing works well. When it is split across columns, hidden in shapes, or replaced by graphics, parsing degrades. Different vendors fail differently, which is why blanket rules mislead candidates.

• Modern engines can usually handle simple tables, but reading order is fragile across vendors.
• Two-column layouts almost always require column detection — and many parsers still get it wrong.
• Icons rendered as font glyphs typically come through as garbage characters or get skipped.
• Images, charts, and shapes are not text — their content is invisible to parsers unless OCR runs (which is rare in ATS pipelines).

Element by element: what works, what breaks

Below is a practical breakdown of common design elements and how they behave inside ATS extraction. The goal is not to scare you away from design — it is to help you decide where the design risk is worth it.

Treat anything tagged 'risky' as something to test with an ATS resume checker before you submit, not as something to avoid forever.

• Tables (single-row data): often parse correctly on modern systems, but cells can merge unexpectedly. Risky.
• Tables (used as layout): high failure rate — content order shuffles after parsing. Avoid.
• Two-column layouts: often parsed as a single jumbled column. Avoid for primary content like experience or education.
• Icons (font-based): may render as boxes, question marks, or be stripped. Keep text labels next to every icon.
• Icons (image-based): not parsed at all. Anything important next to them must repeat as text.
• Skill bars and rating dots: invisible to ATS. Replace with a plain skill list.
• Headers and footers: contact info inside is often skipped. Move name, email, phone into the body.
• Sidebars: parsers may treat the sidebar as a second column or skip it entirely. Avoid for skills, dates, or contact info.
• Photos and logos: not extracted; harmless if all critical text appears elsewhere.
• Hyperlinks (text + URL): generally fine — most ATS extract the visible text. Keep the URL readable too.

Design choices that consistently break ATS parsing

• Putting your job titles or dates in a sidebar — the parser misses them or attaches them to the wrong employer.
• Replacing the skills section with a row of icons or skill bars — keywords disappear and the role match drops.
• Multi-column layouts where the column order does not match the visual reading order.
• Custom symbol fonts (e.g., Wingdings, Material Icons embedded as font glyphs) — characters arrive as junk.
• Tables nested inside tables, or text boxes inside tables — even forgiving parsers stumble here.

Keeping design without sabotaging parsing

• Use color, type hierarchy, and white space to create polish — those are invisible to parsers but powerful for humans.
• If you must use a table, keep it to one row of data (not layout), and label headers clearly.
• Pair every icon with a text label so the meaning survives even if the icon does not.
• Keep skills as plain text in a labeled 'Skills' section — never inside a graphic.
• Test the file in an ATS checker after every layout change, not just at the end.
• Save a parser-safe alternate version (single column, no icons) for portals known to be strict.

How ATS Hiring tests design risk

ATS Hiring runs your file through a parsing simulation and reports which sections came through cleanly, which were degraded, and which design elements likely contributed.

If you want the bigger picture on rejection causes, our guide on why ATS systems reject resumes covers parsing failures end to end. To pair these design rules with a clean build, see our guide on building an ATS-friendly resume.