A reader of resume advice today encounters two genres of formatting guidance side by side. The first comes from 2012: avoid colored fonts, use Times New Roman, never use bold, no graphics, single-column or you'll be auto-rejected. The second comes from 2024: parsers handle most modern formatting fine, the things that actually break them are narrow and specific.

Both are confidently stated. They can't both be right. The 2024 guidance is closer to what the systems actually do today; the 2012 advice survives because the post writers either copied from earlier posts or never ran the test themselves.

This is the sequel to the ATS piece. Where that post was about how parsing works, this one separates the formatting folklore from the real constraints — and tells you what actually matters when you're picking a template.

What modern parsers actually do

A modern ATS parser (Workday, Greenhouse, Lever, iCIMS, and the rest) takes your file — usually PDF or DOCX — and runs it through OCR-adjacent text-extraction logic to pull out structured fields. It looks for:

• Contact info (name, email, phone, location, LinkedIn URL)
• Work history rows with title, company, dates, location, and bullet text
• Education rows
• Skills list

The text extraction works left-to-right, top-to-bottom, and assumes single-column flow. It strips most styling — bold, italic, color — because those don't carry meaning the database can index. It keeps the text content and the document structure (headings, lists, paragraphs).

What this means for formatting: the parser cares about layout that affects reading order and content that's actually image vs text. It doesn't care about cosmetic choices that don't change the underlying text.

Folklore vs. real constraint

Folklore vs. real parser constraint

Format check

Real constraint

• Tables and multi-column layouts (parser scrambles top-to-bottom reads)
• Headers and footers (often dropped entirely)
• Image-only PDFs (no selectable text)
• Unusual section names ('Where I've Worked' vs 'Experience')
• Graphical skill bars and rating widgets

Folklore

• Specific 'ATS-friendly' fonts (any standard font is fine)
• Modest formatting like bold or italics (parsers strip styling)
• Reasonable color use (parsers ignore color)
• Photographs of yourself (parsers skip images, recruiters may have policies)
• Borders, dividers, light decorative elements

The pattern is consistent: real constraints are about whether the parser can read the content at all. Folklore is about cosmetic choices that don't change what the parser sees. A bold heading parses identically to a non-bold heading. A red color in your name parses identically to a black color. A second font parses identically to a single font.

The folklore persists because the advice cost nothing to give in 2012, and the proliferation of safe-looking templates makes it self-reinforcing — readers see "ATS-safe" templates that all use Calibri 11pt and infer that the choice mattered. It didn't. The template just happened to also be single-column and use real section headings, which is what actually mattered.

What the failure-share data shows

Looking at vendor-reported parsing-failure data across major ATS platforms, the share that's caused by each formatting choice is heavily concentrated in three categories:

What actually causes parsing failures

Failure share

Multi-column or table layoutsThe single biggest cause across major ATS

38%

Header/footer-only contact infoPhone or email vanish on parse

22%

Image-only PDFsOften from design-tool exports

17%

Unusual section namesCustom labels miss the bucket

14%

Other (stylized formatting)

9%

Multi-column layouts, header/footer-only contact info, and image-only PDFs together account for roughly three-quarters of all parsing failures attributable to format. Everything else — fonts, colors, decorative elements — is in the noise.

The implication: if you fix the three big ones, you've handled most of the format-driven rejection risk. The rest is over-engineering.

What the parser actually sees

A way to make the abstract concrete: the parser looks at your resume and produces a list of "yes I can read this" and "this is junk to me" items. The yes/no list looks roughly like this:

Format choices · the parser's view

What it sees

Matched · 6

Single columnReal section headingsPlain-text bulletsSelectable PDFStandard date formatInline contact info

Missing · 5

TablesMulti-columnImage-only exportSkill bar graphicsUnusual section labels

If most of your format choices fall in the "matched" list, the parser's reading you correctly. If you've got items in the "missing" list, those are where the silent loss happens.

Specific myths worth retiring

A few that come up repeatedly in advice posts and aren't true in 2024:

"Use Times New Roman or Arial — never anything fancier." Modern parsers handle any standard font. Garamond, Helvetica, Calibri, Source Sans, Inter — all parse identically. The only font failure mode is when text is rendered as an image (from a design tool export), which has nothing to do with the font choice itself.

"Don't use bold or italics — parsers can't read styled text." This was technically true on some 2010s parsers. It hasn't been true on any major ATS since around 2017. Bold a heading; italicize a publication title. The parser strips the styling and keeps the text.

"PDF gets blocked, use DOCX." Most major ATS accept both. A few older systems prefer DOCX, and some company-specific application portals are fussy about file size. The five-second test still applies: if you can copy text from your PDF, the parser usually can.

"Don't include a photograph." The reason here isn't parser-related. Some companies have anti-bias policies that explicitly request resumes without photographs (to reduce identification at the screening stage). Other markets — much of Europe, parts of Latin America — expect them. The parser doesn't care; the policy might. Default to no photograph for US/UK applications, include for markets where it's standard.

"Use a single-column layout — never two columns." This one is real. Two-column layouts confuse most parsers. Single column is the safe choice. Skip the folklore version, keep this rule.

"Don't use colored text." Mostly false. Reasonable color use (a blue heading, a colored accent line) doesn't confuse parsers. The exception is if the color is so light against the background that it fails OCR — which is a contrast problem, not a color problem.

"Avoid all decorative elements." Generally false. Light decorative elements — borders, separator lines, simple icons next to contact info — don't break parsing. Heavily decorative templates with images-as-text or skill-bar graphics do.

What to actually do

The short list of format choices that matter, in priority order:

1. Single column. Don't use a two-column or table-based layout. This is the largest single source of parser failure.
2. Inline contact info. Put email, phone, and LinkedIn in the body of the document, not in a designed page header.
3. Selectable text. Open your PDF and copy a paragraph. If you can copy it, the parser can read it. If not, you have an image-only export problem.
4. Real section headings. Use "Experience," "Education," "Skills." Not "Where I've Worked" or "My Journey."
5. Same date format throughout. Mar 2020 – Present, applied identically to every row.

That's it. Five rules, none of which involve font choice, color, or which template the recruiter saw last.

For everything else — fonts, colors, modest decorative elements, bold-on-headings, italics-on-publications — pick what looks readable and move on. The parser doesn't care, and the recruiter cares more about the content than the template.

When to use a "minimalist" template

Despite all the above, there's still a case for the plainest-possible templates: when you're applying to a high-volume of roles through systems you don't know about, the safe template removes a variable. You won't be the candidate whose resume gets rejected by some specific older parser at some specific company because of a layout choice that 99% of systems would have read correctly.

The cost of the safe template is that it doesn't stand out visually to the recruiter who eventually reads it. For most applicants, that's the right tradeoff — readability for the parser is worth more than visual distinctiveness for the recruiter, given that the parser stage comes first.

If you're applying to design-adjacent roles, or to small companies that don't run a major ATS, or you have a portfolio link that does the visual work, the calculus changes. A more designed resume is fine. The five rules above still apply.