Updated August 13, 2026
What an ATS cannot see: images, icons, charts, headers
A resume can look complete on screen and still be nearly empty to the software that reads it first. Applicant tracking systems do not see your design. They receive whatever text a parser can pull out of the file — and a surprising amount of what candidates treat as content never makes that trip.
This guide is about that gap — content visible to a human but invisible to extraction. It is not about column layout, heading styles, or PDF versus DOCX; those are separate problems in other guides. Here the question is simpler: is the information actually text, or only a picture of text?
The honest answer matters because no formatting trick recovers what was never extracted. If your phone number lives inside a header graphic, a parser does not have a phone number. Fixing that is not about beating an ATS — it is about making sure the words you wrote are words the system can read.
What parsers actually receive
When you upload a CV, the first automated step is text extraction. The system opens your PDF or DOCX and collects character strings — job titles, dates, bullet points, contact lines. It does not receive your font choices, colour palette, icons, or the visual arrangement you tuned.
ResumeTune's parser may report a PDF page count when extraction succeeds, because that number comes from the file structure. It does not claim reliable font or layout metadata — those flags stay off, because inferring fonts or columns from glyph placement is unreliable and would produce false findings.
A tool should report what it can verify from text, not what the page looks like. Invisible-content problems sit upstream of layout debates: if the content never becomes text, layout advice cannot help.
Text baked into images and logos
The most common mistake is treating an image as typed text. Name-and-title banners from Canva, InDesign, or Illustrator render beautifully but store words as pixels. A pasted business-card photo has the same problem.
Logos are fine when purely visual. They become a problem when they carry information you need parsed — your name, headline, certification, or job title rendered only inside the graphic.
The fix is straightforward: anything that must be searchable belongs in real, selectable text outside the image. Keep the logo for polish, but repeat the name and title as plain text the parser can highlight with a cursor.
- Banner headings created in design tools and flattened on export.
- Certification badges where the credential name exists only inside the badge image.
- Screenshots of portfolio snippets or social profiles pasted into the CV body.
- Watermarks or background textures with text baked into the artwork.
Icon-only contact details
Modern templates often replace the words email, phone, and LinkedIn with small icons in a coloured bar. Humans infer the meaning instantly. Parsers do not infer icons — they skip them.
If your email sits behind a mail icon with no adjacent characters, extraction may return nothing for contact. Some systems then leave application fields blank, which creates friction even when a human eventually opens the attachment.
Write contact details as literal text: name@domain.com, +1 555 0100, linkedin.com/in/yourname, city and country if you include location. Icons can decorate beside the text, not replace it.
Charts, skill bars, and infographics
Skill bars, radar charts, star ratings, and percentage rings communicate level at a glance. They communicate almost nothing to a text extractor. A bar filled to eighty percent for Python is a rectangle, not the word Python at eighty percent proficiency.
Infographic timelines fail similarly — employer names and dates on a drawn line often extract out of order or not at all.
Replace visual indicators with a plain skills section: group names, comma-separated lists, or short bullets. Use words for depth — Advanced, Working knowledge — rather than graphics. The human reader still gets the signal; the parser gets characters it can match against a job description.
Headers, footers, and floating text boxes
Word processors and PDF editors let you pin contact details in a header or footer so they repeat on every page. That convenience creates an extraction hazard. Many parsers read the document body first and treat headers and footers as secondary — or skip them entirely depending on the tool chain.
Floating text boxes behave similarly — sidebar summaries may extract out of order, merge with unrelated lines, or disappear. Sidebars built as tables fare better than free-floating boxes.
If something critical lives in a header — phone, email, location — duplicate it in the main body at least once. For summaries and skills, prefer normal paragraph flow over boxed callouts.
Scanned PDFs and image-only exports
A scanned PDF is a photograph of pages. It may print perfectly and look identical to a typed CV, but it contains no selectable text unless someone ran optical character recognition — and many scans do not.
The same outcome happens when an export path flattens a document to images. Some print-to-PDF workflows, mobile scanning apps, and design-tool exports produce files that open normally yet yield no characters when parsed. ResumeTune rejects these as SCANNED_PDF when no usable text is found — not as a penalty, but because there is nothing to score.
Before uploading anywhere, select a sentence of body text with your cursor. If text highlights word by word, you have a text layer. If the whole page selects as one block, re-export from the original editable source — DOCX from your word processor, or a text-based PDF from the app that holds the live document.
How this differs from layout and file-format advice
Three problems get conflated online, and solving the wrong one wastes time. File format — PDF versus DOCX — decides how predictably structure is handed to a parser. Layout — columns, tables, section order — decides whether extracted text stays grouped correctly. Two-column CVs can interleave fragments into nonsense while still containing every word.
Invisible content — this guide — decides whether words exist as text at all. A single-column DOCX with perfect headings still fails if the phone number is an icon and the skills section is a chart. Work in that order when debugging: confirm text exists, then simplify layout, then choose format.
The plain-text paste test
You do not need employer-specific tools to preview invisible-content failures. The paste test approximates what automated extraction sees, stripped of the design that hides problems.
- Open your CV and select all text.
- Paste into a plain-text editor — Notepad, TextEdit in plain mode, or any code editor.
- Read the result from top to bottom.
- Confirm your name, email, and phone appear as readable strings.
- Confirm skills listed only in graphics are missing — that confirms they are invisible, not hidden.
- Confirm job titles still sit beside the correct employer and dates.
Where ResumeTune fits
ResumeTune's free check extracts text from PDF and DOCX and runs deterministic readability and structure checks on what comes back. It reports whether extraction succeeded, whether recognizable sections were found, and — if you paste a job description — which terms appear in the recovered text. The free path uses fixed rules, not an AI model.
It does not inspect fonts, infer column layout, or claim to know how a specific employer ranks candidates. Parser capability flags reflect that honesty: page count may be reported for PDFs when reliable; font and layout metadata are not reported as facts.
If the paste test looks wrong, or ResumeTune returns SCANNED_PDF or thin results, fix invisible content first — move information out of images and icons into plain text — before keyword tuning or format debates. A readable document is the prerequisite for every other improvement.
Frequently asked questions
- What content never reaches the parser?
- Anything that is not real text. Words baked into an image or logo, contact details shown only as icons, values encoded in charts or skill bars, and image-only PDF exports. Header and footer regions are a softer case: they are text, but some systems treat them differently from the body.
- Are email and phone icons enough on their own?
- No. The icon carries the meaning for a human, but the address or number still has to be present as text. An icon beside a blank space extracts as nothing, and contact details are among the most costly things to lose.
- How can I see what a parser sees?
- Copy your resume text and paste it into a plain-text editor. That approximates the extracted text without the visual design that is currently reassuring you, and anything missing from the paste is a candidate for being missing from the record.
- Do headers and footers always get dropped?
- Not always, and the behaviour varies between systems. That variability is the reason to treat the body as the safe place for anything that matters, rather than relying on a header being read.