You spent three hours on your resume. You picked a clean template, lined everything up, added a tasteful sidebar with your skills, a subtle header with your name in a modern font, and a two-column layout that makes good use of space. It looks professional. You're proud of it.
An ATS just read it as scrambled noise.
This is the most common invisible problem in job searching: formatting choices that look polished to a human create extraction failures for the parser reading your file. Not because the ATS is badly built — because parsers are built to read linear text, and modern resume templates are built to look good as visual documents. Those two goals are in direct conflict.
What follows is every formatting rule ATS systems consistently fail on — pulled from the most common rejection patterns — plus exactly what to do instead. Run your resume through an ATS checker after fixing these to confirm the parse improved.
1. Two-Column Layouts
What it looks like: Your resume is split into a narrow left column (skills, contact, education, certifications) and a wide right column (experience and summary). It's compact, modern, and very common in downloaded templates.
Why ATS hates it: Most parsers read documents left-to-right, top-to-bottom across the full page width — the same way a screen reader does. A two-column layout gets read horizontally across both columns simultaneously. The parser extracts text like: 'Python — Senior Product Manager', 'SQL — Acme Corp', 'Stakeholder management — 2019–2023.' The result is an incoherent mix of column one and column two content on the same extracted line. The ATS can't reliably identify your job titles, companies, or dates.
What to do: Single-column layout, full stop. Move sidebar content — skills, education, certifications — below your experience section in the main column. You lose the visual compactness, but you gain a parseable document. Everything that was in the sidebar is still there; it's just not extracted as garbage.
2. Tables
What it looks like: A grid of skills, a two-column list of competencies, an experience section built with invisible table borders for alignment.
Why ATS hates it: Table content is extracted differently depending on the parser and file format. Word documents with tables often produce extracted text where every cell is read out of order, or where entire table contents are skipped. HTML-based parsers handle tables better, but many ATS systems that accept .docx files convert to plain text before parsing — and that conversion drops table structure entirely.
What to do: Replace skill tables with a plain bulleted or comma-separated list under a standard 'Skills' header. Replace any table-formatted experience entries with plain text blocks. If your template uses invisible tables for visual alignment, rebuild the layout using tabs and spacing instead — or switch to a template built in plain text from the start.
3. Text Boxes
What it looks like: A highlighted callout box with a key achievement, a framed summary at the top, a bordered contact info block.
Why ATS hates it: Text boxes in Word documents are stored as floating objects, not as part of the document's main text flow. Most parsers skip floating objects entirely. If your name, contact information, or summary is inside a text box, it may not exist at all in the parsed version of your resume. The recruiter's ATS view of your profile may show a blank name field.
What to do: Move all content out of text boxes and into the document's main body. Your name, phone number, email, and LinkedIn URL should be plain body text at the top of the document — not in a styled box or the document header.
4. Document Headers and Footers
What it looks like: Your name and contact info placed in the Word document header (the area above the top margin) so it prints cleanly on every page.
Why ATS hates it: ATS parsers often skip document headers and footers because they're stored separately from the body text in .docx file structure. This is one of the most common ways contact information goes missing in ATS records — your name and email are right there visually, but the extracted record has blank contact fields. You never get contacted because the system has no way to reach you.
What to do: Put your name, email, phone, LinkedIn URL, and location as plain body text at the very top of the document — the first lines of the file, not in the header zone. Most clean single-column templates do this correctly. If you're using a template where the name bar 'feels' like a header, open the document in Word and check whether that content is in the header layer or the body.
5. Graphics, Icons, and Skill-Rating Bars
What it looks like: Small icons next to section headers, a LinkedIn logo before your URL, skill bars showing 'Proficiency: ●●●○○', certifications displayed with their official badge.
Why ATS hates it: Any content embedded in an image or rendered as a graphic is invisible to text parsers. Skill bars are purely visual — the parser sees no text there. Certification badges don't extract the certification name. Section icons are ignored. The LinkedIn logo before your URL may cause the URL itself to parse incorrectly.
The hidden cost of skill bars specifically: A 'Python ●●●○○' skill bar contributes zero to your ATS keyword score for Python. The skill is listed, it looks clean visually, and the ATS doesn't see it. If Python is a required skill in the JD, your score takes a hit because the bar isn't text.
What to do: Remove all icons and graphics from the document. Replace skill bars with plain text lists — 'Python, SQL, Tableau, Excel' under a Skills header. Certification names should appear as plain text, not as images. Your LinkedIn URL should be plain text, not linked behind a logo.
6. Uncommon Fonts
What it looks like: A stylish font choice — a condensed sans-serif, a modern geometric typeface, a font that came bundled with your template.
Why ATS hates it: Most ATS parsers process text after it's been converted to plain text or a simplified format. Font rendering rarely survives this conversion cleanly. More practically: fonts that aren't installed on the parser's server may cause the document to render differently than you intended, shifting line breaks, character spacing, or — in edge cases — mangling character encoding in ways that produce extraction errors.
What to do: Stick to standard system fonts — Calibri, Arial, Garamond, Georgia, Times New Roman, or Helvetica. These are present on every system, render consistently, and don't create conversion issues. 11pt or 12pt for body text. Nothing smaller than 10pt anywhere.
7. PDFs From Design Tools
What it looks like: A resume designed in Canva, Google Slides, Adobe InDesign, or Figma, exported as a PDF.
Why ATS hates it: PDFs generated from design tools often have broken text layers. The visual layout looks exactly right, but the underlying text data is fragmented — characters stored out of reading order, ligatures encoded as single unrecognizable glyphs, text blocks anchored to visual positions rather than reading flow. Parsers extract this text and get garbage.
There's also a subtler problem: design-tool PDFs often encode text in ways where the parser extracts each line as a separate text fragment with no relationship to adjacent content. A bullet like 'Increased revenue by 40% by reducing checkout friction' might extract as three separate fragments: 'Increased revenue by', '40% by reducing', 'checkout friction' — in no guaranteed order.
What to do: Build your resume in Microsoft Word or Google Docs. Export to PDF directly from Word ('Save as PDF' or 'Export to PDF') — not via print-to-PDF, which also produces visual-only PDFs. Word-exported PDFs preserve the text layer correctly. Google Docs 'Download as PDF' works reliably too.
8. Creative Section Names
What it looks like: 'Professional Journey' instead of 'Work Experience.' 'Core Competencies' instead of 'Skills.' 'Academic Background' instead of 'Education.' 'Things I've Built' instead of anything recognizable.
Why ATS hates it: ATS parsers identify sections by matching header text against a dictionary of expected section names. 'Experience,' 'Work Experience,' 'Employment History' — all recognized. 'Professional Journey' — frequently misclassified as narrative text, not a section header. When a section is misclassified, its content doesn't get scored against the corresponding JD fields.
A misclassified Experience section means the ATS can't extract your job titles, companies, or tenure. A misclassified Skills section means keywords listed there don't contribute to your match score.
What to do: Use standard section names. There is no upside to creative naming here — the audience for section headers is a parser, not a human. Standard headers that work reliably: 'Work Experience' or 'Experience,' 'Education,' 'Skills,' 'Certifications,' 'Projects,' 'Summary.' That's the full list you need.
9. Columns Inside the Skills Section
What it looks like: Your skills listed in a three-column grid — Python in column one, SQL in column two, Tableau in column three — to keep the section compact.
Why ATS hates it: A column layout inside the skills section has the same problem as a full two-column layout — the parser reads horizontally across columns and extracts a scrambled sequence rather than a list of discrete skills. In the worst case, column contents merge into a single unreadable string that doesn't match any keyword.
What to do: List skills as a plain comma-separated list or a simple bulleted list in a single column. 'Python, SQL, Tableau, Looker, Excel, Figma' — that's it. Visually less interesting. Parseable by everything.
10. Fancy Bullet Symbols
What it looks like: Using decorative bullet characters — arrows (→), checkmarks (✓), diamonds (◆), custom Unicode symbols — instead of standard round or square bullets.
Why ATS hates it: Decorative Unicode characters sometimes encode as garbled text or get dropped entirely during plain-text extraction. A bullet that extracts as a strange character sequence can break the word boundary detection that the parser uses to identify keywords — turning 'Managed' into '▸Managed' and causing a keyword miss.
What to do: Use standard bullet characters only — the plain round bullet (•) or a hyphen (-). Both extract cleanly across every parser and file format.
The Pattern Behind All of These
Every item on this list has the same root cause: the formatting choice was made to serve visual presentation, not text extraction. Columns, tables, text boxes, graphics, design-tool PDFs — they all look good to human eyes and produce broken or missing data for parsers.
The fix is not to make your resume ugly. A clean single-column document with strong typographic hierarchy — clear section breaks, consistent date formatting, generous line spacing, a readable font — can look just as professional as a fancy two-column template. See what that looks like in practice. And a format that parses cleanly also satisfies human reviewers — here's how ATS and human review overlap more than most people expect.
The goal is a document where everything the ATS needs to extract is right there in the body text, in reading order, under standard headers, with no visual tricks between the content and the parser. Once you have that, your ATS score measures keyword match against the JD — not formatting failure. That's the only problem worth solving with a score.
Check if your current resume has any of these issues. Upload it and the job link — RolePitch scores your match and flags the specific gaps pulling your score down. Check your ATS score →
More in the ATS Series
- Why your resume gets rejected by ATS — and how to fix it
- How to test your resume against ATS before you apply
- The ATS-friendly resume template that actually works
- How to read your ATS score and what each section means
- ATS vs human resume review: what each one actually looks for
Turn the insight into your next application.
RolePitch helps you check, tailor, and download a resume version built for the role you want.
See how RolePitch works →