Most resume advice focuses on what to say. This post is about something that fails earlier and more silently: whether an applicant tracking system can read your resume at all. Before any keyword matching or recruiter search happens, the ATS has to extract your text and map it into structured fields — name, job titles, dates, skills. A two-column template with icons and a text-box sidebar can turn a strong resume into scrambled noise at that step, and you will never know. Here is exactly which formatting choices parse cleanly, which ones break, and how to test yours.
This is the formatting companion to our strategy guide, How to Beat the ATS. That post covers keywords, tailoring, and ranking; this one covers the layer underneath — making sure the parser receives your content intact in the first place.
How ATS parsing actually works
An ATS doesn't "look at" your resume the way a human does. The typical pipeline is:
- Text extraction. The system pulls raw text out of your file — from a PDF's text layer or a DOCX's XML. If the text isn't there (an image) or comes out in the wrong order (multi-column layouts), everything downstream fails.
- Segmentation. The extracted text is split into sections by recognizing headings like "Work Experience" and "Education."
- Field mapping. Within each section, the parser identifies entities: company names, job titles, date ranges, degrees, skills.
- Storage and search. The structured record goes into a database recruiters filter and search.
The critical detail: extraction is linear. The parser reads text in the order it sits in the file, not the order your eye travels across the page. A design that looks organized to a human — skills on the left, experience on the right — can extract as interleaved fragments, with sidebar lines spliced into the middle of job descriptions.
If you can select all the text in your resume, copy it, and paste it into a plain text editor in the correct reading order — your resume will survive almost any parser. Everything below follows from that test.
File type: PDF vs DOCX vs images
Three rules cover nearly every case:
- Text-based PDF is the safest default. It locks your layout, renders identically everywhere, and modern parsers read it well. "Text-based" matters: the PDF must contain selectable text, not a picture of text.
- DOCX is equally parseable when the document is clean (no text boxes, no tables for layout). Use it when an application form explicitly asks for Word. The downside is that fonts and spacing can shift on the recruiter's machine.
- Images and scans are unreadable. A JPG, PNG, or scanned PDF contains no text layer. Some systems run OCR as a fallback, but many don't — assume your content vanishes. The same applies to resumes exported from design tools as flattened graphics.
Quick check: open your PDF and try to select a sentence with your cursor. If you can't highlight individual words, it's an image and needs to be re-exported from the source document.
Single column beats everything else
Multi-column templates are the single most common formatting failure. Parsers that read left-to-right across the full page width stitch your sidebar and main column together line by line, producing text like "Senior Analyst Python Acme Corp SQL 2021–2024 Communication." Field mapping has no chance after that. Three related offenders:
- Tables used for layout. Some parsers read tables row-by-row, some column-by-column, some skip cell content entirely. A two-cell table holding "dates | job details" can detach every date from its job.
- Text boxes. In Word, text boxes float outside the main document flow. Many extractors ignore floating objects completely — anything inside can simply disappear.
- Columns within sections. A three-column skills grid can still extract out of order. A comma-separated skills line is just as scannable and always safe.
One top-to-bottom column, with content in normal paragraph and list flow, parses correctly in essentially every system. It also happens to be faster for humans to skim.
The header and footer trap
In Word (and templates derived from it), the page header and footer are separate document regions — and some parsers extract only the main body, skipping both entirely. Since templates love putting your name, phone, and email in the page header, the failure mode is brutal: a perfectly parsed work history attached to an anonymous candidate with no contact details.
Put your name and contact block at the top of the main body, as ordinary text. If you want a footer with page numbers, fine — just never put information there that you can't afford to lose.
Fonts and sizes
Fonts rarely break extraction in a properly exported PDF, but they affect both edge-case parsing and human readability:
- Stick to widely available fonts: Arial, Calibri, Helvetica, Georgia, Garamond, or similar. Decorative and script fonts can map glyphs unpredictably and read poorly anyway.
- Body text at 10–12pt, headings at 12–16pt. Shrinking to 8pt to cram everything in hurts humans more than machines — if you're fighting for space, the fix is editing, not font size. See how long a resume should be.
- Avoid non-standard encodings from design tools, which can extract ligatures like "fi" as broken characters. Exporting from Word, Google Docs, or LaTeX with standard fonts avoids this.
- Never use white or near-invisible text to hide keywords. Parsers extract it, recruiters can see it in the parsed view, and it reads as deception.
Section headings the parser recognizes
Segmentation works by matching headings against known labels. Standard headings map cleanly:
- Work Experience (or Professional Experience, Employment History)
- Education
- Skills (or Technical Skills)
- Certifications, Projects, Summary
Creative headings — "My Journey," "Toolbox" — may not match anything, so the content beneath them gets dumped into an unclassified bucket or attached to the wrong section. Boring headings are a feature. Keep them on their own line, visually distinct, and never embedded inside graphics or banner shapes.
Dates: format them like a parser expects
Date ranges drive how the ATS calculates your experience, so make them unambiguous:
- Use Month Year – Month Year ("Mar 2021 – Jun 2024") or plain years. Both parse reliably.
- Write "Present" for current roles — parsers expect that exact word.
- Keep dates adjacent to the role they belong to, in a consistent position for every entry. Alternating layouts confuse field mapping.
- Avoid ambiguous numeric-only formats like "03/21 – 06/24," and never put dates in a separate table column.
Graphics, icons, photos, and charts
Anything rendered as an image contributes nothing to extraction:
- Skill bars and donut charts are the worst offenders — "Python ████░" extracts as "Python" at best, with the proficiency information lost, and gives a recruiter no real signal anyway.
- Icons replacing words fail silently: an envelope icon instead of the word "Email" can leave the field unlabeled. Include the actual text.
- Photos add parsing risk and, in many markets, bias risk. Unless you're applying somewhere photos are the norm, leave it off.
- Logos and decorative graphics are usually ignored harmlessly, but they occasionally trip extractors and earn you nothing.
What parses vs what breaks
| Element | Parses cleanly? | Safer alternative |
|---|---|---|
| Text-based PDF or clean DOCX | Yes | — |
| Image, scan, or flattened PDF | No | Re-export with a selectable text layer |
| Single-column layout | Yes | — |
| Two-column / sidebar template | Unreliable | One column, skills as a labeled line |
| Tables for layout | Unreliable | Plain text with consistent line structure |
| Text boxes (Word) | Often skipped | Normal body text |
| Contact info in page header/footer | Often skipped | Contact block at top of the body |
| Standard section headings | Yes | — |
| Creative section headings | Unreliable | "Work Experience," "Skills," "Education" |
| "Mar 2021 – Present" dates | Yes | — |
| Skill bars, charts, icons-as-data | No | Words and numbers in plain text |
The safe template recipe
If you want a formula instead of a rulebook, this layout parses everywhere:
- Top of body: name on its own line, then one line with phone, email, city, and LinkedIn URL as plain text.
- Summary (optional): two to three lines, no heading gimmicks.
- Work Experience: for each role — job title, company, location, "Month Year – Month Year," then 3–5 bullet points using standard round bullets.
- Skills: a labeled, comma-separated line or simple list — this is also where your keyword work lives (see the resume keywords guide).
- Education, then Certifications if relevant.
- One column. Standard font, 10–12pt body. No tables, text boxes, images, or content in the page header/footer.
- Export as a text-based PDF (or DOCX if the form demands it).
Within that container, write whatever makes you compelling. The container's only job is to deliver your content to the parser undamaged.
How to test your resume's parseability
Don't guess — test, in increasing order of rigor:
- The copy-paste test. Select all text in your PDF, paste into a plain text editor. Is everything present, in reading order, with dates next to the right jobs? This catches images, text boxes, and column scrambling in thirty seconds.
- The application preview. Many application forms auto-fill fields from your uploaded resume. If the auto-filled titles and dates are wrong or empty, that is the parser telling you exactly what it sees.
- A dedicated checker. Rankd's free ATS checker shows you the extracted view of your resume and flags formatting problems alongside keyword gaps, so you can fix both layers at once.
Once your resume parses cleanly, formatting is solved — permanently, for every application. From there, the work that moves your ranking is content: matching the actual language of each job, covered in How to Beat the ATS.