7 min read
Templates love a tidy band across the top. That band repeats on every page because it lives in a header region, not because it's part of your experience bullets.
And if you've been copying the same DOCX for months, you might not notice the header still holds your phone line from an old template swap.
Check your resume for free on the PDF you'll upload. If extracted text skips your email, you're still stuck: the apply form may accept the file while the recruiter grid stays blank.
Tonight you'll confirm which layer holds your contact block, move it if needed, and run one paste test. That's the whole job for this failure mode.
This won't fix a role you're underqualified for. It stops a qualified file from looking headless inside Workday or Taleo.
Quick wins
- Double-click the top margin: dimmed body means header mode.
- Cut contact lines into the first body paragraph, then clear the header.
- Paste all PDF text into Notepad; your email should appear before Experience.
Why the screen lies but the parser does not
A Word or Google Docs header is a separate structural region. In a DOCX zip, body text and header text often sit in different XML parts. The renderer merges them for your eyes. Extraction code that only walks the body never sees what you typed in the margin.
Contact info in a header breaks ATS parsing when the import builds candidate fields from body text alone.
PDFs follow the same risk when export keeps header metadata. Some exports flatten everything; others preserve layers. You cannot tell by opening the file, so you test the file you will submit.
Before: You assume the recruiter sees the same string you see at the top of page one.
After: You treat the paste test as the source of truth, not the preview pane.
Before: You blame silence on keywords when email never imported.
After: You fix the contact block before you rewrite bullet one.
For what happens after upload when fields stay empty, read what happens to your resume after submission . Parsers run before humans sort.
Greenhouse and Lever often handle plain body text well. Older Taleo builds and some Workday imports still drop margin content. Putting contact info in the body is the safe default across employers.
Multi-page resumes can hide a second header on page two. Check section breaks before you assume page one is the only risk.
Move the block without redesigning the page
Work on the file you plan to upload. Five minutes of cut and paste beats a week of wondering why nobody emailed you back.
Word or Google Docs
- Double-click the top margin until header mode activates, then cut name, phone, email, and URL lines.
- Click the first body line, paste, and add a blank line before Summary or Experience.
- Reopen the header on every section; clear Different First Page duplicates.
- Export PDF and run the verification paste below.
Copy-paste verification (read the first lines after paste):
{`Open exported PDF (not the editor)
Select all text → copy → paste into Notepad
Line 1 should be your name
Line 2 should include email and phone
If paste starts with "Experience" or "Summary", header still holds contact info`}
I've opened Workday previews where experience imported cleanly and the email field stayed empty because the address lived in a Word header. The fix was boring: paste into the body, export again, same visual layout.
Text boxes beside your name fail the same way. If you use a sidebar layout, see why ATS rejects resumes with text boxes while you're checking extraction order.
Layout habits that keep contact info invisible
- Leaving phone and email in the header because the template shipped that way.
- Trusting Print Preview instead of a plain-text paste from the PDF.
- Putting the LinkedIn URL only in a footer on page two.
- Using icon fonts for phone and envelope with no plain-text label.
- Re-uploading the same broken export because the portal accepted the file size.
Before: You add keywords while contact fields stay blank upstream.
After: You confirm name and email import before you tailor bullet one.
Portals that ask you to retype email anyway still use parsed text for search and dedupe. Empty extraction hurts you twice.
Fancy two-column contact rows in tables can scramble order even when nothing drops. Keep one plain line under your name when you can.
Confirm extraction on the real file
Run the export you'll attach to the req. Fix contact placement before you chase keyword lists.
Run the free ATS check and read the extracted text at the top. Name, email, and phone should appear in order. If you're rebuilding from scratch, build your resume in a single-column layout that keeps contact lines in the body by default.
When a posting also wants a letter, draft it after the resume grid passes. Use the cover letter generator for a plain file, then customize the opening line. Don't let letter polish delay a contact fix on a closing req.
Body text is the contact field
Does putting contact info in headers break ATS parsing? For many imports, yes. The failure is silent until you paste plain text or read an extraction preview.
Move the block, clear empty headers, export once, verify once, then tailor. That's enough for this issue tonight.
Job searching is draining enough without fighting a template margin. You're making sure recruiters can reply, not decorating a band they'll never parse.
Read more
Frequently asked questions
Often yes. Many parsers walk the main body stream first and never open header or footer parts of a DOCX or tagged PDF. Your file can look perfect while extracted text starts at a section heading and leaves email and phone fields empty upstream.
Double-click the top margin in Word or Google Docs. If the editor dims the page and switches into header mode, that block is not body text. Export PDF, select all, paste into Notepad: if the paste begins with Experience or Summary and skips your email, the contact block is still trapped.
No. Cut from the header, paste as the first lines of the body, and reapply bold or centering. You are changing which layer stores the text, not the visual layout.
Page numbers in a footer are usually fine because recruiters do not need them parsed. The risk is essential content: name, email, phone, city, and profile URL belong in the body, not in a repeating header or footer band.
