# Contact details in page margins: nothing lost, everything moved

> Margin contact details scored 100% recovery but 93.7% order. Phone and email landed at the end of the extracted resume text.

|  |  |
| --- | --- |
| Category | Resume formatting |
| Published | July 31, 2026 |
| Reading time | 10 min |
| Rendered page | https://atsprep.com/blog/resume-header-footer-contact-details |
| This document | https://atsprep.com/blog/resume-header-footer-contact-details.md |

Placing contact details in the page header or footer is common in polished resume templates. The name sits at the top, the email and phone sit in the margin, and the visual hierarchy is clean. We tested this layout across 9 profiles. Recovery was perfect: 100%. But the contact line did not stay where it was placed. It moved to the very end of the extracted text, a long way from the name it belongs to. This is the mildest real finding in the study, and it is still worth understanding.

## The short version

- Recovery was 100% and welding was 0%. Nothing was lost or fused.
- Reading-order fidelity dropped to 93.7% because the contact line relocated to the end of the text.
- A reader works down the page by coordinate. Margin content sits outside the main text flow and is processed last.
- If software looks for a phone number near a name, distance matters even when nothing is missing.

## What happens when contact details sit in the margins

A PDF page has a content area and margins. Text placed in the margins, typically through a header or footer, is stored with coordinates that sit above or below the body text. A reader processes fragments by position, usually top to bottom, and margin content can end up being read after everything in the main content area.

In our test, the contact line (email, phone and city) was placed in the page header area. The name was in the body. When the reader extracted the text, the contact line appeared at the very end, after Education, rather than near the top where a reader would expect it.

This is not extraction failure. Every word came back. Every email address was intact. The order changed, and only in one specific way: the contact details moved from near the top to the bottom.

*The four-stage pipeline. Margin content enters at stage two with coordinates outside the body area, and is grouped last at stage three.*

## What the extracted text looks like

Here is the verbatim output from the header-footer condition. The name is at the top, the experience, skills and education follow in perfect order, and then the contact line appears at the very end.

In the ground truth, the contact line was the third line from the top, immediately below the name and title. In the extracted output, it is the last line. The distance between the name and its contact details went from two lines to the entire length of the document.

Every other line is in the correct position. There is no welding, no word loss, no structural damage. The only change is the location of that one line.

> **Keep in mind:** The last line is marked because it has been relocated, not because it was fused from unrelated content. The welding metric for this condition is 0%.

*Verbatim extraction from the header-footer condition. The contact line landed last, far from the name.*

```text
Jordan Rivera
Senior Backend Engineer
EXPERIENCE
Senior Backend Engineer, Northwind Systems
2022 - Present
- Migrated 47 services from virtual machines to Kubernetes across three regions.
...
EDUCATION
BS Computer Science, University of Texas at Austin, 2019
jordan.rivera@example.com | 555-0142 | Austin, TX
```

## The metrics in context

The header-footer condition scored 100% word recovery, 93.7% reading-order fidelity, and 0% welding. Email addresses were 100% intact. Block integrity was 100%.

Compare that with the two-column layout: 97.9% recovery, 83.6% order, 30.5% welding. The margin layout is better on every axis. The only departure from the control is the order score, and that reflects a single relocated block rather than systemic interleaving.

This is the mildest real finding in the study. It is worth reporting because the mechanism, content relocating based on coordinate position, is the same mechanism that causes the more severe problems in other layouts. Understanding why it happens here helps explain why it happens everywhere.

*Header-footer contact details compared with the control and two-column layouts.*

| Layout | Recovery | Order | Welded |
| --- | --- | --- | --- |
| Single column | 100% | 100% | 0% |
| Contact in margins | 100% | 93.7% | 0% |
| Two columns | 97.9% | 83.6% | 30.5% |

*Reading-order fidelity across selected conditions. The margin layout loses order without losing words.*

|  | Value |
| --- | --- |
| Single column | 100% |
| Contact in margins | 93.7% |
| Table grid | 93.4% |
| Two columns | 83.6% |
| Scanned image | 0% |

## Why distance matters even when nothing is missing

If a system is scanning the extracted text for keywords, the location of the contact line does not matter. The email address is present; a regex will find it anywhere in the text.

But if software is trying to build a structured profile, associating a name with an email and a phone number, proximity is a useful signal. Many parsers assume the contact block is near the top of the document, close to the name. When it lands at the bottom, after education, the association weakens.

This is a softer failure than welding. Nothing is corrupted. The information is all present and all correct. It is simply not where a reader, human or automated, expects it to be. Whether that matters depends entirely on how the downstream system works.

## A related case: the rotated sidebar

The rotated-sidebar condition behaved similarly. It scored 100% recovery, 100% order and 0% welding. The body text was completely untouched. The rotated skills list was recovered, but it appeared at the end of the document, in reverse order.

The mechanism is the same: a reader works by coordinate, and rotated text sits at coordinates that do not correspond to the visual reading position. The text is extracted, but it lands somewhere unexpected.

Both cases fall into the same category: content that survives extraction but relocates. Neither is catastrophic. Both are avoidable. And both illustrate the same underlying principle: a reader's idea of where text belongs is defined by coordinates, not by the designer's intent.

*Conditions where content survived but relocated.*

| Condition | Recovery | Order | Welded | What moved |
| --- | --- | --- | --- | --- |
| Contact in margins | 100% | 93.7% | 0% | Contact line to end |
| Rotated sidebar | 100% | 100% | 0% | Skills to end, reversed |
| Single column | 100% | 100% | 0% | Nothing |

## What to do about it

The simplest fix is to keep contact details in the body of the document rather than in the page margins. Place them directly below the name, as inline text, and they will stay in that position through extraction.

If you prefer the visual effect of margin-placed contact details, know that the information will survive but may relocate. Test the result by pasting the extracted text and confirming that the email and phone appear near the name.

For rotated sidebars, the same principle applies. The content survives, but it will not appear where the eye expects it. If the rotated content is purely decorative, the relocation is harmless. If it contains information a system needs to associate with other parts of the resume, it may not be found where expected.

- Place contact details in the body, directly below the name, for the most reliable extraction.
- Margin-placed contact details will survive but may land at the end of the text.
- Rotated text is recovered but appears at the end, potentially in reverse order.
- Test by extracting and checking whether the contact block sits near the name.

> **Keep in mind:** One reader was tested: PDF.js, the same library the X-ray runs. Employer systems use different extractors and may produce different results. Findings describe how these formatting choices behave under extraction, not how any particular company screens.

## Study limits

The corpus is synthetic: all 108 files were generated with pdf-lib rather than collected from real applicants. This means every variable is controlled and the intended text is known exactly, but it also means no one's personal data is involved.

One reader was tested: PDF.js, the same library the X-ray runs. Employer systems use different extractors and may produce different results. Findings describe how these formatting choices behave under extraction, not how any particular company screens.

The margin placement we tested used a single header region. Some templates use both headers and footers, or split contact details across multiple margin positions. Those configurations were not tested and may produce different relocation patterns.

## Sources and further reading

1. [PDF.js](https://mozilla.github.io/pdf.js/), Mozilla
2. [pdf-lib](https://pdf-lib.js.org/), pdf-lib
3. [Semantic Structure — WebAIM](https://webaim.org/techniques/semanticstructure/), WebAIM

## Related

- [We generated 108 resume PDFs to find what breaks text extraction](https://atsprep.com/blog/resume-pdf-extraction-study.md)
- [What happens when a PDF reader hits a two-column resume](https://atsprep.com/blog/two-column-resume-extraction-test.md)
- [How to see what an ATS reads in your resume](https://atsprep.com/blog/see-what-ats-reads-in-your-resume.md)
- [Resume headers and footers in PDF and DOCX text extraction](https://atsprep.com/blog/resume-header-footer-text-extraction.md)

## About ATSPrep

ATSPrep (https://atsprep.com) is a free resume and application workspace. Match experience to a posting, strengthen claims with evidence, and track the next action. Its PDF check shows text recovered by ATSPrep's extractor, not an employer's proprietary ATS or hiring decision.

- **Price:** Free plan forever: your ATS score, every fix, job match, 5 AI edits a day and PDF downloads, with no card or watermark. Optional ATSPrep Pro ($5/month, or $24 once for 6 months) adds 300 AI edits a day, Fix all with AI, AI tailoring, Word downloads, all 7 templates and unlimited practice with Pip.
- **Account:** none needed to import or edit a resume, or for its first check and 3 rechecks a day. A free sign-in is needed for PDF downloads (Word files come with ATSPrep Pro), to sync, and for more than 1 AI edit.
- **Your file:** parsed and exported inside the browser. The resume file itself is never uploaded.
- **Sent:** matching a job by meaning, on by default once you add a job (the lines involved). Only on a button press: AI edits (the lines involved), a job link (the link) and Pip voice calls (your speech). Never your contact details, and none of it is stored.
- **Connection:** some tools load on first use and need a connection to download. Local storage is not a cloud backup.
- **Accepts:** PDF, DOCX, TXT, Markdown, or pasted plain text.

Start here: https://atsprep.com/studio