The header is the most-redesigned part of a resume. Candidates spend hours iterating on layout — sidebar or no sidebar, color block behind the name, tagline under the title, icons next to email and phone. Most of this work is invisible to recruiters and actively breaks parsing on a non-trivial fraction of ATS systems.

This post is the honest story: which header designs survive, which break, and what the design value of a fancy header actually is.

The two-axis decision

The header decision splits along the same lines as most resume-design decisions: industry conservatism and application channel. The intersections matter.

Conservative industries via ATS portal are the highest-risk combination. A finance, legal, or government recruiter receiving your application through Workday wants a clean, traditional header. The ATS is parsing aggressively into structured fields; a graphical header risks blank name fields and miscategorized contact info. Plain text wins.

Creative industries via direct submission are the lowest-risk. A creative director receiving your portfolio link and PDF directly can appreciate a designed header, and there's no ATS in the path. This is where graphical headers earn their keep — and even here, restraint reads better than excess.

The two mixed quadrants — conservative direct, creative ATS — are where the most candidate confusion lives. The general rule: when in doubt, lean toward plain text. The parsing risk is bigger than the design upside.

What goes wrong with fancy headers

The failure modes are well-documented in ATS parsing studies, and they're worse than candidates realize.

Name not extracted from image-based header. If your name is rendered as part of a graphic or as a custom font that the parser doesn't recognize, the recruiter's view shows a blank name field. The candidate has to be manually identified by HR. About a third of fancy-header resumes hit this.

Contact info mis-mapped. Phone number ends up in the email field; LinkedIn URL ends up in the website field. The recruiter sees the data but it's in the wrong slot. Some ATS systems route follow-up emails to these mis-mapped fields, which means your application never reaches you.

Title or location parsed into summary. Your role title and city get pulled into the free-text "summary" field rather than the structured ones. The recruiter searching by location or title doesn't find you in their saved-search results.

Sidebar parsing. A left-aligned sidebar containing skills, contact info, or summary frequently parses out of order — the right-side content appears first, then the sidebar appears at the bottom. The recruiter scrolling the parsed view sees a jumbled document.

For the broader ATS landscape, see how-applicant-tracking-systems-work and ats-friendly-resume-format-myths.

The header that always works

The pattern that survives every parser and reads cleanly to recruiters is plain. Four lines, top-of-page, left- or center-aligned:

Maria Chen
Senior Product Manager
San Francisco, CA · maria.chen@email.com · 415-555-0142 · linkedin.com/in/mariachen

That's it. Name as plain text, role title as plain text, contact info on one line separated by dots or pipes. No images. No sidebars. No icons next to email and phone. The contact info should be live text, not embedded in graphics — Workday and Greenhouse extract these into structured fields and you want that extraction to succeed.

If you want one visual element, the safest is a thin colored rule under the contact line. A 1-2px navy or charcoal line, edge-to-edge, separating the header from the rest of the document. This is purely decorative — no parser is fooled by it, no parser breaks on it — and it gives the resume one small design beat without risk.

What to avoid:

• Name rendered as an image or in a custom font the parser doesn't know.
• Text inside colored boxes. Some ATS systems strip the box and the text together.
• Sidebar with contact info. Left or right sidebars frequently parse out of reading order.
• Icons replacing labels. Phone icon next to a number is fine; phone icon instead of the word "Phone" can sometimes hide the field. Either keep the labels or skip the icons.
• "Brand" elements. Initials in a circle, logo-style monograms, hand-drawn signatures. All of these read as decoration and add no signal.

What about taglines?

A one-line tagline under your name — "PM building data products for B2B SaaS" — can work, but it lives in a fragile zone. Some parsers categorize it correctly as a headline; some pull it into the summary; some skip it entirely.

If you use a tagline, treat it as bonus and not load-bearing. The actual signal — your role, experience, and what you do — should live in the summary section below, not depend on the tagline being read.

For broader summary structure, see resume-summary-section.

What about photo headers?

The short answer: don't include a photo on a U.S. or U.K. resume. Most ATS systems strip photos; many recruiters in those markets are trained to discard resumes with photos to reduce bias liability. In other markets (parts of continental Europe, Latin America, some Asian markets), photos are conventional. The decision is regional, not personal preference.

If you're applying internationally and your region expects a photo, place it small in the top-right corner, in a conventional headshot crop. Don't make it the visual anchor of the page.

What about international addresses, multiple phone numbers, or two cities?

A common over-design pattern: trying to fit a long contact block with two phones, two emails, a personal website, and a portfolio URL. The header gets cluttered, parsers struggle, and recruiters miss what matters.

The minimum: one phone, one email, one LinkedIn URL, one city. Anything else (portfolio, GitHub, personal site) can go in the second line if relevant to the role. Drop anything that isn't.

What this isn't

A few clarifications:

• It's not "boring wins always." Creative industries do value design literacy. The point is that the header is a high-risk zone — design elsewhere on the page if you want to signal design taste.
• It's not the only parsing issue. Headers are one of several places parsers fail. See headers-footers-in-resume-parsing for the related document-headers-and-footers problem.
• It's not a guarantee. Even a clean header can parse oddly in older or quirky ATS systems. The plain-text version reduces risk; it doesn't eliminate it.

The short version: plain-text header with name, title, location, and contact info on one line. One optional thin rule for visual punctuation. No sidebars, no boxes, no images. The design upside of a fancy header is small; the parsing downside is larger; the boring version wins for most candidates in most channels.