ATS CV Templates and How to Check Yours Parses

Most "ATS-friendly" CV templates come with a claim and nothing behind it. The designer says it parses, you take it on faith, and the first person to actually check is a recruiter looking at a candidate profile with your job title sitting in the skills field. This guide takes the opposite approach. For every layout decision that matters, you'll see what a parser extracts from it, so you can judge a template by its output rather than its marketing.

The short version up front. An applicant tracking system (ATS) does not read your CV the way a person does. It extracts the text, guesses at the structure, and rebuilds your career as a set of database fields. A template is ATS safe when that rebuild comes out accurate. Everything below follows from that one mechanic, which is worth understanding before you pick a design. If you want the fuller background, start with how an ATS actually works.

ATS safe means a parser can read the file's text in the correct order and map each block to the correct field. Systems like Workday, Greenhouse, iCIMS and Taleo take your CV apart and store it as structured data, with separate fields for employment history, for education, for skills, for certifications. Recruiters then search and filter on those fields. If your dates land in the wrong field, a filter for "5+ years of experience" can miss you even though you qualify.

That definition rules some things in and some things out. It rules in plain text, one reading path down the page, and headings the parser recognizes. It rules out anything the text extractor cannot see or cannot order, no matter how clean it looks to a human.

Notice what is missing from that list. Nothing about color, nothing about bold text, nothing about whether the template looks modern. Plenty of formatting is harmless. The list of things that genuinely break parsing is short, which is why the next section shows each one with its actual damage.

The honest way to evaluate a template is to run content through a parser and read what comes back. Do that with the popular "designed" CV layouts and the failures repeat in predictable patterns. Here are the four big ones, each with an example of what the extracted text looks like.

A parser working through a PDF's text layer often reads line by line across the full page width. On a two-column CV, that stitches the left column into the right, one horizontal slice at a time.

Look at row two. The parser now has to decide whether the job title is "Data Analyst" or "SQL Data Analyst" and whether "Python" belongs to the employer name. Sometimes it guesses right. The problem is that you never see the guess, because the scrambling happens after you hit submit.

Content placed in a floating text box sits outside the document's main text flow, and many extractors skip it entirely or dump it at the end of the output, detached from everything around it. Skill bars are worse. A bar showing "Excel ████░" contains no words at all, so the parser extracts nothing. Your proficiency in Excel simply does not exist in the candidate profile, and a recruiter filtering on that skill will never find you.

Icon-driven contact rows fail the same way. A telephone glyph followed by a number extracts as a bare number with no label, and some parsers cannot tell it apart from a ZIP code or an ID. Write "Phone:" as a word.

Some templates lay out each job as a table row, with company in one cell and dates in another. A parser that walks the table column by column reads every company first, then every title, then every date range. The output looks like this.

Once dates detach from jobs, the system's calculated years of experience are wrong, and that number feeds recruiter filters. This is the most expensive failure on the list because the CV still looks fine to a human reviewer who opens the original file. The database copy, the one that decides whether you surface in a search, is corrupted.

Word-processor headers and footers are a separate layer of the document, and some extraction engines ignore that layer. The result is a parsed profile with an empty name field or a missing email, which forces the recruiter to open the original file to contact you. Many won't. Put your name and contact line in the body of the document, as the first text on the page.

Parsers extract information into structured fields, and they find those fields by recognizing section headings. "Work Experience" triggers the employment-history extractor. "Where I've Made an Impact" triggers nothing, so everything under it either gets misfiled or attaches to whatever section came before. The heading is an instruction to the machine, and the machine only speaks a small vocabulary.

The rule is boring on purpose. Save the personality for your bullet points, where it belongs and where a human will actually read it. A heading exists to route content into the right database field, and the conventional label does that job every time.

To a parser, it doesn't. The software has no concept of "CV" as distinct from "resume". It sees a document, extracts the text and maps the sections. A UK or European CV and a US resume go through identical machinery, so every formatting rule on this page applies to both. If you're applying to US companies, our ATS resume format guide covers the same structure from the resume side.

The distinction matters in two practical ways. First, length. A two-page CV parses exactly as well as a one-pager; parsers do not penalize length, humans do, so let the norms of your market and seniority decide. Second, academic CVs. A publications list or a grants section has no dedicated field in most systems, so it lands as unstructured text. That's fine. It won't break anything, and the humans who hire for research roles read the original document anyway.

One more thing outranks formatting entirely. Knockout questions in the application form, on work authorization or a required certification for instance, can disqualify you automatically no matter how cleanly your CV parses. Resume review itself generally stays with a human. Answer the form questions carefully; they carry more automatic rejection power than any layout choice.

Here is the honest answer, because the internet gives you two dishonest ones. "Two columns always fail" is outdated; some modern parsers handle some two-column PDFs correctly. "Modern ATS handle columns fine" is overconfident; whether a specific two-column PDF parses depends on the reading order embedded in its text layer, which varies by the tool that produced the file and which you cannot see by looking at the page.

So the question is really about risk. A two-column CV built in a tool that writes a clean, column-aware text layer can parse perfectly. The identical design exported from a different tool can interleave like the table above. You cannot tell which you have without testing, and the failure is silent, so the safe default is a single column. If you love a sidebar design, keep it for the version you hand to a human at a networking event, and run the test in the next section before you ever upload it to an application portal. More of the folklore around this gets sorted out in our piece on common ATS myths versus reality.

You do not need special software to catch the failures above. Two checks expose almost all of them, and neither takes longer than a minute.

Run the first two checks on any template before you commit to it, including templates sold as ATS safe. The full walkthrough, with what each result means, is in our guide to testing your resume against an ATS.

A safe template is easy to make unsafe. Most parsing failures I see in the wild were introduced during editing, on a layout that started out clean. Four habits keep it intact.

Keep the headings standard as you personalize. Renaming "Skills" to something clever is the most common self-inflicted wound, and the table above shows why. Change the content under the headings, never the headings themselves.

Pick one date format and use it everywhere. A parser can handle "Mar 2021 – Present" and it can handle "03/2021 – Present". What trips it is a document that mixes both, plus a stray "Summer 2019", plus one entry with no dates at all. Consistency is what makes the pattern recognizable.

Paste as plain text. Copying bullets from an old document drags hidden styles along, and those can reintroduce the exact structures you chose the template to avoid. Paste unformatted, then restyle inside the editor.

Write keywords the way the posting writes them, with evidence attached. Matching inside modern systems is moving beyond raw keyword counts toward skills-based and contextual matching, so a bare term in a skills list is worth less than the same term inside a result. "Built Tableau dashboards that cut weekly reporting from six hours to one" beats "Tableau" sitting alone. Our guide to pulling resume keywords from a job description covers how to find the terms worth mirroring.

The final failure point is the export itself. An ATS must extract usable text before it can search or pre-fill anything, so a scanned page or a flattened image gives the parser literally nothing, even if the underlying design was perfect. Some design tools export exactly that by default. Canva, for example, can produce a PDF where the text has been rasterized into pixels, and the select-all test comes back empty.

The check takes five seconds. Open the exported PDF and try to highlight a sentence with your cursor. If the text selects, a parser can read it. If your cursor draws a box instead, you exported an image and need to change the export setting to a print or text-based PDF.

Submit as PDF by default. A text-based PDF preserves your formatting on every machine and parses cleanly; switch formats only if a specific employer's instructions explicitly demand something else. This is also where your builder choice quietly matters. Roleframe's editor exports a PDF that matches the editor exactly, with a real text layer, and the editor is free to use with no account, so the select-all test passes by construction. If you want a starting point that has already been through this whole gauntlet, our collection of ATS friendly templates that parse cleanly is built on the same parse-and-verify method as this article.