Can an ATS Read Tables? Check Your Resume

A table can look neat in Word and still fall apart when an applicant tracking system reads the file. Parsers do not see columns. They see a stream of text. If the cells come out in the wrong order, the job title, the employer, and the dates can land in the wrong fields. I have not run a lab across Greenhouse, Workday, or Lever, and this page does not publish a pass rate. The check you can trust is your own: paste the resume into a plain-text editor and read the jobs in order.

Skip any chart that claims a percentage of resumes fail because of tables. No vendor number like that is cited here. If the plain-text paste keeps each role together, a parser can probably read the file. If the paste mixes a date from one job with a title from another, fix the layout before you worry about keywords.

Why do tables break when a parser reads them?

A person reads a table by looking across a row. Title on the left, dates on the right, company underneath. A parser does not have eyes. It walks the document in the order the file stores the text, which is often cell by cell, and sometimes column by column. A three-column row that looks like Senior analyst, Northwind, 2022 to 2024 can come out as three titles in a row and three date ranges later. Search then looks for the employer in the wrong place and misses you.

The same thing happens with a skills table, a header table used only to line up the phone number, and a two-column template where the left side is a sidebar. The border you see is not a border the database keeps. Once the grid is gone, only the order of the words remains. That order is the whole resume, as far as the search box is concerned.

What does a scrambled table look like in plain text?

Imagine a row built to align three jobs. On the page it is easy to scan. In a text box it can collapse into a list of titles, then a list of companies, then a list of dates. A recruiter who searches for the company name may still find the file. A filter that expects the current title in the current role field may not. You will not see that mismatch while you are looking at the designed PDF.

Table paste: Analyst. Manager. Lead. Northwind. Brightpath. Harbor. 2024. 2022. 2019.
Line paste: Analyst, Northwind, 2022-2024. Owned the weekly ops report.
Line paste: Manager, Brightpath, 2019-2022. Ran the onboarding checklist for new hires.

The second shape is dull. It is also the shape a stranger can read without guessing which date belongs to which job. Dull is the point. A hiring manager can still get a designed PDF by email if a person asked for one. The file you upload into a portal should be the dull one.

Which layouts cause the same problem?

• A table whose only job is to align dates with job titles.
• A two-column resume where work history sits in one column and dates sit in the other.
• Text boxes for the summary or the contact block.
• A skills grid of icons, stars, or bars instead of words.
• A header or footer that holds the email address and nothing else.
• A scanned PDF, or a Canva export that is really a picture of text.

Columns are the cousin of tables. If you paste a two-column file and the skills list appears in the middle of a job, the parser is doing the same thing: reading the stored order, not the visual order. Sidebars are fine only when the jobs themselves stay in one full-width column and the paste test still reads top to bottom.

How should a role be written instead?

Put the title, the employer, the city, and the dates on consecutive lines. Then the bullets. Then the next role. Do not merge cells to make the dates sit in a pretty right margin. Do not use a tab stop you cannot see after export. A simple heading plus a short list survives copy and paste, and it survives the import step that copy and paste is standing in for.

• One role, then its dates, then its bullets, before the next role starts.
• A normal font such as Arial, Calibri, or Georgia. Body text around 11pt.
• Headings a person would search for: Experience, Education, Skills.
• Skills as words, not as a bar chart.
• Contact details in the body of page one, not only in the PDF footer.
• A .docx from Word or Google Docs, or a PDF exported from those tools.

Does a keyword list fix a broken table?

No. Keywords help after the text is in the right fields. If the parser never stored your last job as a job, adding the posting's tools to a skills footer does not repair the history. Fix the order first. Then read the job ad and add a term only where the work is real. Stuffing the advert into the file does not make a scrambled table parse.

This is also why an ATS score on a website is not the same thing as a parse check. A score can count overlapping words. It does not show you the string the database stored for the employer field. The paste test is closer to that string than a percentage is. If you want a keyword gap list after the layout is clean, use the checker and keep the decision about each word.

What about PDF, Word, and designed templates?

A PDF from Word is usually fine. A PDF from a design tool often is not, because the text is placed as separate boxes. Some portals ask for PDF only. Export from Word or Docs anyway, not from a poster template. If you keep two files, the words should match. A designed version for a person and a plain version for a portal is reasonable. Two versions that disagree on your title are not.

Google Docs and Word both let you build a table in two clicks. That does not make the table a good structure for a job history. Use them for a draft if you want, then flatten the jobs into lines before you upload. The same advice sits in the longer formatting guide: single column, common font, standard headings, and a paste test before a batch of applications.

How do you run the plain-text test?

• Export the file you will actually upload, not the working draft.
• Select all, copy, and paste into Notepad, TextEdit, or any editor that shows no columns.
• Read the first role. Title, employer, and dates should sit together.
• Read the second role. It should not start halfway through the first one's bullets.
• Search the paste for a tool you believe is on the resume. If it is missing, the portal will miss it too.
• If the order is wrong, rebuild that section as lines and test again.

Thirty seconds is enough. You are not grading the prose. You are checking whether a machine can tell your jobs apart. If it cannot, a recruiter searching the database cannot either. I built CVPage AI in Dubai to flag weak lines and missing keywords. It will not repair a table you never flattened, and it will not invent a layout test result.

What should you leave alone?

A one-column resume that already pastes cleanly does not need a redesign. Changing fonts every week does not help. A simple table used once for a short certification list is a smaller risk than a table that holds your whole career, but the paste test still applies. If that list comes out as a readable line, keep it. If it comes out as a jumble, write the certifications as a sentence.

Creative roles sometimes want a visual file in the email and a plain file in the form. Send both when the instructions allow it. Do not send only the visual file to a portal and hope. The person who opens the designed PDF is not the search box that runs first.

You can see that reading order on your own file in the ATS resume parser test

The longer note on fonts, columns, and file types is ATS-friendly CV and resume format

After the paste reads cleanly, compare keywords with one job ad in the ATS resume checker

A Canva design and a PDF are different questions. The file-type note is can ATS read a Canva resume or a PDF?