Stop sending PDFs. Start sending links.

If you've applied to a job in the last decade, your resume PDF has been parsed by software you've never seen, by a vendor you've never heard of, in a company different from the one you're applying to. The output gets dumped into a database. The recruiter sees the database row. They might glance at the PDF; they might not.

This is the part of the hiring process nobody describes to candidates honestly: your beautifully-typeset PDF is not, in any meaningful sense, the document the company sees. The company sees what the parser made of it.

The parsers are bad.

What actually happens to your PDF

Modern Applicant Tracking Systems do something like this when they receive your resume:

1. Extract text from the PDF — usually with a generic library, not one tuned for resumes.
2. Run a heuristic to figure out which line is your name, which is your title, where the experience section starts, where it ends.
3. Try to break the experience section into one row per job. Get the company name. Get the title. Get the dates.
4. Try to extract education. Try to extract skills. Try to extract a phone number.
5. Hand the result, full of guesses, to the recruiter.

The most expensive resumes — the ones with hand-tuned columns, custom typography, sidebars, photos, two-column layouts — break the parser the worst. The parser sees columns as a flat reading order and produces something like Acme Corp, Tech Lead, Senior Engineer, 2019-2022, 2022-Present, Built scalable, Led team — a smooth blend of two different jobs into one nonsense row.

You can verify this yourself. Most of the time, applying through a careers portal, after you upload the PDF, the next page has a form pre-populated with the parsed data. That form is what the recruiter sees. Skim it. It's usually wrong somewhere.

The version-control problem

The other thing that happens with PDFs is that you make a few of them.

You have resume.pdf. Then you have resume_v2.pdf with the new job added. Then a tailored version, resume_acme.pdf, with the bullet about distributed systems moved to the top. Then resume_v3_final.pdf and, inevitably, resume_v3_final_FINAL.pdf. Then you send the wrong one.

When you spot the typo two days later, the PDF you sent is sitting frozen on a recruiter's desktop. There is no fixing it. The applicant tracking system has the PDF and the parsed row. Both are now wrong. The only way to update is to email and explain, which most people will not do.

A link does not have this problem. The link points at a profile that's always current. You change a bullet, the link reflects it. You can update your phone number after you've already applied somewhere, and the next time anyone clicks the link, they get the new number.

A link does both jobs

Here's the trick: the same link can serve a human and a parser well, at the same time, without compromise.

A human visits a Klypn profile (klypn.com/p/<id>) and gets a clean, readable page — name, title, work history, education, skills, contact info. Nothing surprising.

A company's ATS hits the API at /api/v1/applicant/<id> and gets the same data as structured JSON — experience: [...], education: [...], skills: [...] — already broken into the right fields. No parser. No heuristics. No mystery columns.

The recruiter sees the page they expected. The ATS sees the data it expected. Both are reading from the same source, which is whatever you typed in last.

This isn't theoretical. The API is live. The contract is documented. Companies that integrate it stop running PDFs through the parser entirely.

The 5-second message you send a recruiter

Hey, here's my profile: klypn.com/p/abc123 — let me know if you want me to send anything else.

That message works in 2026 in a way that "see attached resume.pdf" no longer does. It's faster to share. It's faster for them to scan. They can refresh the page in a week and see whatever you've added. If they hand the link off to their hiring manager, the hiring manager sees the same thing they did.

The PDF model assumes the document is the artifact. The link model assumes the person is the artifact, and the document is just the current view of them.

What's left for PDFs

To be fair: PDFs aren't going away tomorrow. Some application forms will not accept anything else. Some companies have decade-old internal pipelines that expect a file. You'll need a PDF sometimes.

But you should default to sending the link. Drop the PDF only if the form requires it. And — quietly — assume the parsed version of your PDF is wrong somewhere, and that the version they actually have is whatever they pulled off the link.

It's a smaller, less impressive document. It's also the one that works.

Try it. Two minutes to upload, no account required to start.