You've probably seen it a hundred times: "Never use tables on your resume." It's one of those rules that gets repeated so often it starts to feel like gospel. And like most gospel, there's real truth in it, but also a fair amount of oversimplification. The reality is that some ATS platforms handle simple tables reasonably well, while others scramble them completely. The difference isn't random. It comes down to which system a company uses, how that system parses documents, and what kind of table you've placed in your resume.
This article isn't here to tell you tables are fine. It's here to help you understand the actual risk so you can make an informed decision, not just follow a rule you heard somewhere without context.
98%+
Fortune 500 Companies Use ATS
Near-universal adoption among large employers as of 2026
41%
Parse Error Rate in Taleo
Of resumes with complex formatting submitted to Taleo, per TalentTuner analysis of 40,000+ submissions
~1 in 4
Parsing Failures Tied to Formatting
Formatting issues are a leading driver of ATS parsing failures across major platforms
First, Understand the Landscape
ATS isn't one thing. It's a category of software, and the platforms within it vary enormously in age, architecture, and capability. Workday, Taleo, Greenhouse, iCIMS, and Lever are among the most widely used systems across enterprise hiring. Understanding how they differ is the foundation for understanding the table problem.
Two Generations of ATS
- Legacy ATS (e.g., Taleo)
- Built in the 1990s and early 2000s, these systems use positional parsing, reading a document from top-left to bottom-right like a typewriter. They were designed for plain-text, ASCII-era resumes. Tables break this model in predictable and frustrating ways.
- Modern ATS (e.g., Greenhouse, Lever, Workday)
- Newer platforms use more sophisticated parsing engines, and some are integrating AI and natural language processing capabilities. These systems are more forgiving of certain formatting choices, but still not immune to table-induced errors.
How Tables Actually Fail (And When They Don't)
When a table breaks in an ATS, it doesn't just look a little off. The content can become genuinely unreadable to the system, invisible to recruiters reviewing your parsed profile. One documented case: a job seeker's resume with tables had only the work experience section successfully parsed. The ATS completely skipped their skills section, contact information, profile summary, and portfolio links. Those qualifications simply didn't exist in the system.
The specific failure modes depend on the platform. Taleo often scrambles table cell contents, reading them in unpredictable order due to its positional parsing logic. Some modern systems may merge cell contents from the same row into a single string. Even a simple two-column skills table with Technical Skills on the left and Soft Skills on the right can parse as one jumbled line: "Technical Skills Soft Skills Python Leadership SQL Communication". Or the second column gets skipped entirely.
How Major ATS Platforms Handle Tables
| Platform | Table Tolerance | Parsing Approach |
|---|---|---|
| Workday | Low - may merge or drop cells | Modern engine with NLP features, but sensitive to layout complexity |
| Taleo | Very Low - high failure rate | Legacy positional parsing; built for plain text |
| Greenhouse | Moderate - simple tables may parse | Shows PDF to recruiter; parsed fields appear as sidebar metadata |
| iCIMS | Low - unreliable with tables | Strict parsing; formatting errors common |
| Lever | Moderate - partial table support | More modern engine; still struggles with nesting |
Greenhouse is among the more table-tolerant of the major enterprise platforms, and there's a structural reason for that. Greenhouse's primary recruiter view is a rendered version of your uploaded PDF, with parsed fields appearing as supporting metadata in a sidebar. That means a visually strong, well-organized PDF can partially compensate for imperfect parsing. But "more tolerant" doesn't mean "safe." It means the risk is lower, not eliminated.
The Distinction That Actually Matters
Not all tables carry the same risk. The critical distinction is between data tables and layout tables, and most resume advice conflates them.
Table Type Matters More Than Table Presence
Data Tables
Single-row or simple structured tables used to display actual information, like a row of certifications or a two-column skills list. These are 'risky' per ATS parsing research: they often work on modern systems but can merge unexpectedly. Still worth avoiding if you're applying at scale.
Layout Tables
Tables used as design scaffolding to create columns, position headers, or control visual spacing. These have a high failure rate across all major ATS platforms. Nested tables or text boxes inside tables cause failures even on forgiving parsers. Avoid entirely.
The Risk Calculus: Can vs. Should
Here's where the nuance becomes practical. Some modern ATS platforms can parse simple tables. That's true. But job seekers rarely know which ATS a specific employer uses before applying. And "can parse" is different from "parses reliably across every employer on your list." A resume with a two-column layout might display correctly in one system and lose a significant portion of its content in another.
The argument that blanket avoidance advice is outdated has some merit. The preference for single-column resumes emerged from real technical limitations in early ATS implementations, and some argue that the advice has outlasted the technical limitation for modern platforms. But most evidence still favors avoidance when applying through online portals at scale, because you cannot control which system receives your resume.
A Simple Test You Can Do Right Now
The Plain-Text Parsing Test
Open your resume file
Use your PDF or DOCX version, whichever you'd actually submit to an employer.
Select all and copy
Use Ctrl+A (or Cmd+A) to select everything, then copy the full text content.
Paste into a plain text editor
Open Notepad (Windows) or TextEdit in plain text mode (Mac) and paste. No formatting will survive. Just the raw text.
Read it as a parser would
Is the information in a logical order? Is anything missing? Are sections scrambled or merged? If a skills table existed, do the contents read in a sensible sequence, or is it a jumbled string?
That result is your ATS parse
What you see in the plain text editor is roughly what older ATS systems see. If it's readable and complete, you're in good shape. If sections are missing or out of order, you have a formatting issue worth fixing before you apply.
Safe Alternatives to Tables
The good news is that the things job seekers typically use tables for (organizing skills, aligning dates, creating visual structure) all have universally parseable alternatives. You don't have to sacrifice readability to get reliability.
Table Replacements That Parse Cleanly
Do This
Avoid This
Skills listed with vertical bar separation: Python | SQL | JavaScript | Tableau
Two-column table with Technical Skills on the left, Soft Skills on the right
Comma-separated skills list under a plain 'Skills' heading
Nested table used to create a sidebar layout for contact information
Tab stops for date alignment, keeping dates right-aligned without a table structure
Table used as layout scaffolding to create columns across the full resume
Simple bullet points under each role, cleanly organized in a single column
Text boxes or tables within tables used to frame certifications or awards
Do This
Skills listed with vertical bar separation: Python | SQL | JavaScript | Tableau
Avoid This
Two-column table with Technical Skills on the left, Soft Skills on the right
Do This
Comma-separated skills list under a plain 'Skills' heading
Avoid This
Nested table used to create a sidebar layout for contact information
Do This
Tab stops for date alignment, keeping dates right-aligned without a table structure
Avoid This
Table used as layout scaffolding to create columns across the full resume
Do This
Simple bullet points under each role, cleanly organized in a single column
Avoid This
Text boxes or tables within tables used to frame certifications or awards
When Tables Might Actually Be Fine
Context matters, and there are situations where the ATS parsing risk is low or irrelevant. If you know your resume is going directly to a human (emailed to a hiring manager you've connected with, or submitted through a direct portfolio site), visual clarity may matter more than parse reliability. Creative and design roles, where a well-formatted document is itself a portfolio signal, are another context where the calculus shifts.
- Direct email to a hiring manager: No ATS in the path, so formatting choices are about human readability only.
- Creative or design roles: Visual presentation carries meaning; a PDF that demonstrates design judgment may outweigh parsing risk.
- LinkedIn Easy Apply or direct portfolio sites: The resume may be viewed as a file rather than parsed into a database.
- Applying at scale through online portals: This is where parse reliability matters most. Stick to simple, linear formatting.
The version of your resume you send through an online application portal and the version you hand to a contact at a networking event can (and perhaps should) be different documents. One is optimized for systems; one is optimized for people. Having both is a reasonable strategy, not a compromise.
The Evolving Landscape
ATS platforms are not static. Modern systems are integrating AI-powered candidate scoring, semantic search, and workflow automation at a meaningful pace. Newer platforms are increasingly capable of understanding contextual relationships between phrases, capabilities that simply didn't exist in the legacy systems that gave rise to most resume formatting rules.
What this means for tables: the risk is genuinely decreasing on modern platforms over time. But legacy systems still hold significant market share across enterprise hiring. The safe play today isn't the safe play forever, but it's the right call right now. Format for the systems you can't see, and you'll never be caught out by the ones you didn't expect.
Key Takeaways
- Tables are not universally fatal to ATS parsing, but they fail often enough to be a meaningful risk, especially on legacy platforms like Taleo.
- The type of table matters: data tables are risky, layout tables should be avoided entirely.
- Greenhouse tends to be more table-tolerant than Taleo, and you rarely know which one you're submitting to.
- The plain-text paste test is a fast, free way to catch parsing issues before you apply.
- Safe alternatives (vertical bar separation, comma lists, tab stops) deliver the same organizational clarity without the parsing risk.
- Context matters: direct applications to humans carry different formatting logic than online portal submissions.
- The 'ATS-friendly' label is unregulated and meaningless. Judge a template by its structure, not its marketing.
Frequently Asked Questions
Will an ATS automatically reject my resume if it has a table?
No. ATS systems score and sort resumes; they don't auto-reject. But parsing failures from tables can cause your qualifications to be scored incompletely or inaccurately, pushing your resume lower in the candidate pool where recruiters may never reach it. The effect can feel like rejection, but it's a visibility problem, not an automatic disqualification.
Is a two-column resume the same as using a table?
Not always, but often in practice. Many two-column resume templates use tables as the underlying structure to create that layout. When you paste the text into a plain text editor, you'll see immediately whether the columns parse in a readable order or collapse into a jumbled sequence.
Can I use a table in the skills section specifically?
A simple single-row data table for skills is lower risk than a layout table, but it still isn't reliable across all platforms. Vertical bar separation (Python | SQL | R) achieves the same visual organization and parses cleanly on every major ATS. It's the safer choice with no real tradeoff.
If Greenhouse shows recruiters the actual PDF, does formatting matter less there?
Somewhat. Greenhouse's primary view is the rendered PDF, so a visually well-organized document helps. But Greenhouse also parses metadata into a sidebar for recruiter filtering. If your skills section fails to parse because of a table, it may still be missing from those fields even if the PDF looks fine to the eye.
How do I know which ATS the company I'm applying to uses?
In most cases, you can't know for certain before applying. The application portal URL often gives a clue: if it contains 'workday,' 'greenhouse,' 'lever,' 'icims,' or 'taleo,' that's the system. But for blind applications, the safest strategy is formatting that performs well across all of them.