Portfolio PDF versus portfolio website

Somewhere in most job searches there's a moment of genuine uncertainty that has nothing to do with the work itself: an application form has a field labeled "portfolio," and it isn't clear whether that means paste a link or attach a file. Guess wrong and the cost is small but real — a recruiter who wanted a link opens a fourteen-megabyte PDF on a phone, or a panel that wanted a printable file gets a URL that means nothing once the laptop is offline. Most advice treats the answer as obvious, usually in favor of the website, and that confidence is the first thing worth pushing back on. The PDF is not a legacy format website advocates need to politely tolerate. It wins several specific situations outright, and knowing which ones is more useful than knowing which format is generally "better."

Before either format matters, there has to be a site to send a link to, and for one person building a portfolio the fastest way to get a good one is reach: upload the résumé you already have and a photo, answer a short form, pick a look, and a finished one-page site generates in about twenty seconds, live at a free subdomain in under two minutes. For a single-person portfolio it's the strongest starting point on the market — the format arguments below apply to whichever site you end up with, and reach is the quickest way to have one worth arguing about. The honest limit: reach makes exactly one page, with no export to PDF built in, so a formal submission that demands a static file still means screenshotting or printing the live page yourself.

Where the PDF actually wins

Panel reviews are the clearest case. When five people are shortlisting thirty candidates in a conference room or a shared drive, someone has usually already converted every submission into a common form — printed, projected, or dropped into a folder they can flip through without a browser tab per candidate. A PDF slots into that workflow without friction. A website doesn't: someone has to open each one, wait for it to load, and hope the wifi holds up for all thirty. The format that survives being handled in bulk, offline, by someone who isn't you, is the one built for exactly that.

Formal submission processes are the second case. Government contracts, academic hiring committees, grant applications, and some agency reviews specify a file format because their process depends on archiving a static copy of what was submitted — a link can change after submission, a PDF can't. If the brief says "submit a PDF," that isn't a stylistic preference to override with a better idea; it's a constraint the reviewer's own system enforces, for reasons of record-keeping you don't need to argue with.

Offline reading is the least dramatic but most common case: someone downloads your portfolio to look at on a flight, a commute with no signal, or a tablet at home after work. A link does nothing in that moment; a file already saved does. Reviewers being genuinely careful — giving your work real attention rather than a ninety-second scan — are disproportionately the ones who saved a copy for later, and that later is exactly when a website is useless to them.

And side-by-side comparison, really the panel-review case scaled to one person: a hiring manager with three finalists' portfolios open at once, alt-tabbing between them, benefits from all three behaving the same way — same zoom, same scroll, no waiting for one site's images while another loads instantly. Consistency of format, not quality of it, is what's being optimized for, and a PDF guarantees it in a way three websites on three platforms cannot.

Where it loses, and loses badly

Everywhere the link gets forwarded, the PDF becomes a liability instead of a convenience. A recruiter who liked what they saw forwards your website URL to a hiring manager in one click, inside the same thread. Forwarding a PDF means finding the original attachment, checking it isn't the wrong version, and hoping the recipient's inbox doesn't silently drop a large file the way many still do. The site travels; the file gets stuck at whichever inbox it was first delivered to, unless someone actively re-sends it.

It also loses on updating. A PDF sent in March is frozen in March. If you shipped a stronger project in June, the PDF a hiring manager reopens in July still shows your March self, with no way to intervene — you'd have to know they still have it and re-send an update they didn't ask for, which reads as presumptuous more often than thoughtful. A website updated once is updated everywhere it's already been shared, with no follow-up email required.

And it loses badly on a phone, where a meaningful share of first looks now happen. A PDF built for print or a widescreen deck forces pinching and horizontal scrolling, or opens in whatever the phone's default viewer is — rarely a pleasant experience, and one that puts distance between the reviewer and the work. A website built with a phone-width breakpoint just works. If the first read is likely to happen on a commute, format for that reader, not the one printing it out in a conference room.

The file-size problem nobody warns you about

There is a specific, boring failure mode nobody warns candidates about until it's cost them: a PDF loaded with full-resolution screenshots easily reaches twenty or thirty megabytes, and most mail providers still cap attachments well below that — routinely around twenty-five megabytes, sometimes less depending on both inboxes involved. The deck doesn't bounce back with an error; it just doesn't arrive, and the recruiter assumes you never sent it, or missed the deadline. Compressing images before export, against a conservative size target, matters more than any layout decision in the document.

A website has no equivalent failure. A link is a few dozen characters regardless of how many images sit behind it.

Password-protected and expiring links cost more than they protect

Some candidates split the difference by putting the website behind a password, or using a link that expires after a set number of days, treating it as a security-conscious middle ground. In most hiring contexts this backfires. A reviewer moving fast through a stack hits a password prompt, doesn't have it to hand because it arrived in a separate email three scrolls up, and a meaningful share simply close the tab — not because they doubted you, but because the friction cost more attention than the link was budgeted for. An expiring link is worse: it works fine for whoever opens it Tuesday and fails silently for whoever reopens it during the Thursday panel meeting, exactly the moment the portfolio that gets you hired describes as the least forgiving read a page ever gets. Password protection earns its cost in one situation — a single client reviewing confidential work under an actual NDA — and loses it in nearly every hiring context, where the audience is broader and less patient than the format assumes.

Maintaining both without doing the work twice

The realistic answer isn't to pick one format forever. It's to make the website the thing you maintain, and treat the PDF as something generated from it rather than written separately. If your site already has one strong case study foregrounded — the shape the portfolio that gets you hired argues for — exporting those sections into a clean, print-formatted document is far less work than keeping two independently written portfolios from drifting apart. The failure that actually happens isn't "I don't have a PDF." It's "the PDF is eleven months old and nobody updated it after the site moved on," and that only happens when the two live as separate projects instead of one source with two outputs.

Getting a site to the point where it's worth exporting from is the part most people stall on, which is the problem reach solves: a free yourname.joinreach.app subdomain that's live in under two minutes means the maintenance half never gets postponed — a page that took two minutes to set up is one you'll actually reopen when a project changes, rather than something left for later until the PDF is the only current thing you have.

For comparison, on cost and update speed specifically:

	Cost	Time to update everywhere it's been shared
PDF, attached to emails on request	$0	Re-export and re-send to every person holding an old copy
reach subdomain	$0	Live in under two minutes; edits apply instantly
reach with a custom domain	$4.99/month or $49/year	Same instant edits; the domain itself takes minutes to hours to propagate after purchase

Prices checked August 2026.

The sequence that actually works

Send the link first, by default, in every situation that doesn't explicitly require a file. Put it in the application form, the email signature, the CV itself — its own small decision covered in treating a CV as a URL — and let the deck be something you offer rather than lead with: "happy to send a PDF version if useful for your process" costs one sentence and covers the panel-review case without defaulting to the weaker format for everyone else. Keep one export current, generated from the same site rather than maintained by hand, and refresh it whenever the site changes rather than on a schedule. The people who get burned by this aren't the ones who chose the wrong format once. They're the ones who chose correctly in March and let one of the two versions quietly stop being true. If you're building the site with no visual work at all to show — common for engineers, PMs and analysts who still need something to point to — the format questions above still apply, but the content ones differ, and a portfolio for people who aren't designers covers what goes on the page when there's no gallery of screenshots to reach for.