Tables, graphics, and other parsing risks.

1. The underlying principle

Parsing works by extracting text characters from a file and reconstructing the visual reading order. Anything that breaks the correspondence between "where the text appears on the page" and "where the text appears in the file" is a parsing risk.

Common offenders either:

• Move text out of the main body — text boxes, headers, footers, floating elements.
• Store text in a structure the parser has to interpret — tables, multi-column grids.
• Bake text into an image — logos, infographics, screenshots of text, image-based PDF exports.

2. Tables

Tables are the most common "visual" layout choice on resumes. A common pattern is a two-column table for skills (skill name on the left, proficiency on the right), or a table for contact details.

Parsing tables is harder than parsing prose. Different parsers handle tables differently:

• Some extract table content as a linear text stream, cell by cell, which produces a confusing list.
• Some read rows first, then columns — matching the visual order for a single row but not for the whole table.
• Some skip table content entirely if it's not what they expected.
• Some handle tables well.

For any application with automated parsing, avoid tables. Use simple text layout instead. For contact details, a horizontal line of separated items works fine. For skills, a comma-separated list or a short paragraph works fine.

3. Text boxes

Text boxes are a specific type of floating element that text extraction often mishandles. Common issues:

• The text inside is ignored entirely.
• The text appears at the end of the extracted stream, detached from its visual position.
• The text is read only partially.

Avoid text boxes for any content you need parsed. Contact details, name, and any critical content should be in the main document body.

4. Images containing text

Text inside images is invisible to a text extraction parser unless the parser has OCR (optical character recognition) enabled. Most ATS parsers do not run OCR by default.

Common examples:

• A logo or monogram with your name — fine to include for design, but don't rely on it for identification.
• Skills listed inside an infographic — invisible to parsing.
• A "skills rating" graphic with stars or bars — the rating is invisible; the skill name is only visible if it's text outside the image.
• A scanned PDF — the entire resume is an image. Extremely risky to submit to an ATS.

If you want visual elements on your resume, use them as decoration, not as carriers of information. Any skill, contact detail, or experience should exist as text in the document body.

5. Headers and footers

Content placed in the header or footer of a document is treated inconsistently by parsers. Some ignore it, some mix it into the middle of the body, some repeat it. If you have your name and contact in a running header on every page, this can cause:

• Duplication of your contact details in the parsed content.
• Contact details mixed into the middle of a bullet or paragraph.

The safest option is to put contact details only in the header section of page one, as body content — not as a Word header or running header.

6. Columns and grids

Multi-column layouts have been covered in the simple layouts article. The short version: columns are risky because the parser may not know whether to read across or down.

If you want a two-column feel, consider:

• A full-width header band with your name and contact details, then a single-column body.
• Sidebar content moved into a "Skills" section at the top or bottom of the resume, as normal text.

7. Fonts and special characters

Unusual fonts can cause problems, especially symbol fonts or fonts used for decorative elements. Modern OCR and text extraction handles most standard fonts (Inter, Arial, Calibri, Times New Roman, Georgia) without issue.

Also watch for:

• Bullets — some fonts have unusual bullet characters that don't parse consistently. Standard round bullets (•) are safest.
• Special characters — em dashes (—), en dashes (–), and non-breaking spaces sometimes produce strange results in extracted text. Not typically a rejection cause, but can cause field mapping failures.
• Ligatures — typographic ligatures (fi, fl, etc. as single characters) sometimes extract as missing characters.

8. Section names

Section names matter because parsers often use them to identify where one section ends and another begins. Standard names that parse reliably:

• Experience — sometimes "Professional Experience", "Work Experience"
• Education
• Skills — sometimes "Technical Skills", "Core Skills"
• Summary — sometimes "Professional Summary", "Profile"
• Certifications, Projects, Languages

Non-standard names that may not parse reliably:

• "Career Journey", "My Story", "Where I've Been" (for Experience)
• "What I Know", "My Toolkit" (for Skills)
• "The Learning Path", "Growth" (for Education)

Creative section names may look nice on a visual template, but they increase parsing risk. If parsing matters, use standard names.

9. Practical checklist

• Have you avoided tables for layout or content?
• Is all content in the main body, not in text boxes or headers/footers?
• Is any critical information free of images (not baked into graphics)?
• Is the layout single-column, or if multi-column, tested for extraction?
• Are section names standard?
• Have you exported to PDF from a text-based source (not scanned)?