What a Parser Does With Your Links

Your resume probably carries three or four addresses: an email, a professional profile, maybe a personal site or a code repository. In the document they are neat, blue, and clickable. After extraction they may be neat, unclickable, and pointing nowhere, because the part a human clicks and the part a machine stores are two different pieces of data.

This is a small problem with an annoying consequence: the one field on your resume whose whole purpose is to lead somewhere is the one that quietly stops leading anywhere.

Anchor text versus the address

A hyperlink has two halves. There is the text you see — Portfolio, LinkedIn, my GitHub — and there is the address it points to, stored separately as an attribute of that text.

Text extraction pulls the character stream. The character stream contains the visible text. The address is not part of the character stream; it is metadata attached to a region of it. Whether an extractor also collects link targets varies, and it is not something you can find out from the outside.

So consider a contact line that reads:

What you wrote (rendered):
  Ada Okafor · Columbus, OH · Email · LinkedIn · Portfolio

What plain-text extraction can return:
  Ada Okafor · Columbus, OH · Email · LinkedIn · Portfolio

Nothing is corrupted. Nothing is out of order. And there is no email address, no profile, and no site in the record at all. A recruiter reading the parsed view sees the word Email where an address should be.

The same thing happens with a mailto: link on the word “here,” a phone number hyperlinked as Call me, and a repository linked from the phrase “the source is on GitHub” inside a bullet point.

Write the address as the text

The fix is one rule, and it removes the whole problem: the visible text of every link should be the address itself.

Ada Okafor
Columbus, OH · ada@example.com · +1 614 555 0100
linkedin.com/in/adaokafor · adaokafor.dev

Now the address is in the character stream. If the extractor also captures the link target, fine — you have it twice. If it doesn’t, you have lost nothing. There is no version of this that goes wrong.

A few details worth getting right:

• Drop the scheme prefix and the www. for readability if you like; a bare adaokafor.dev is unambiguous to a reader and still a valid string to search for. Keep the scheme if your editor insists on autolinking either way — it does no harm.
• Don’t shorten URLs. A shortener produces an opaque string that tells a reader nothing, cannot be verified without clicking, and dies when the shortening service does. It also looks evasive on a document whose job is verification.
• Don’t use tracking parameters. A long query string after the path is noise, and clean URLs are the convention across this site’s advice for a reason.
• Watch the autoformatting. Editors love turning a typed URL blue and underlined. That is fine — it is still real text underneath. What is not fine is an editor that replaces the typed URL with a friendly label, which some do when you paste a link.
• Check for a hyphen turning into a dash. A URL containing a hyphen can get auto-converted to an en dash, producing an address that reads correctly and resolves to nothing. This is one of the failure modes in the characters that extract wrong.

Where the link sits matters too

Extraction can lose a link for structural reasons that have nothing to do with the hyperlink itself.

In a text box or a sidebar. A contact block implemented as a floating frame may be skipped entirely, address and all — the case described in why your two-column resume breaks.

In a page header or footer. Same region problem. Your site address at the foot of every page can extract zero times.

Inside an image. A profile URL set in a designed banner is a picture of a URL. See when your resume is a picture.

Split across a line break. A long address wrapped mid-string can extract with a space or a hyphen inserted at the wrap point. Keep addresses short enough to fit one line.

QR codes

A QR code is an image that encodes a string. Extraction reads text; it does not decode images. To a parser, a QR code on your resume is a decorative square that contributes nothing — and it occupies space where the address itself could have been printed.

There is also a plain human problem with it. Someone reading your resume is very often reading it on the screen where their phone camera is not usefully pointed, or reading a printout of a screenshot, or reading it inside an applicant tracking system’s preview pane. Asking them to pick up a second device to reach your portfolio adds a step to a process you want to be frictionless.

If you love the code, keep it and print the address next to it in text. Never as a replacement.

The one thing links buy you that text does not

None of this is an argument against having links. It is an argument about how to write them. An address in plain text is still clickable in most viewers, because most viewers autolink anything that looks like a URL — so writing the address out usually costs you nothing even in the human-facing version.

What you gain is that the address becomes part of the record. It is searchable, it survives being copied into an application form, and it appears in the parsed view a recruiter reads rather than only in the attachment. When a form autofills from your file, as in when the application form autofills from your resume, a website field can only be populated from a string that extraction actually produced.

Check it

Copy your resume, paste it into a plain text editor, and look only at what you can now read as text.

1. Count the addresses. Every email, profile, and site you meant to include should be visible as a full address. If you see the word Portfolio and no domain, that link is gone.
2. Copy each address out of the plain text and paste it into a browser. This catches dash substitutions and wrap-point damage that look fine on the page.
3. Search the plain text for http. Anything that appears should be a complete, correct address, not a fragment.
4. Cover the QR code with your thumb and ask whether the resume still tells a reader where to find you.

If every address survives as text, your links are as durable as the rest of the document — and you can stop worrying about whether a given extractor collects link targets, because you no longer depend on it.