Portfolio Website or PDF Portfolio: Which Should You Send?
If your portfolio lives in a long PDF, it is probably a careful document. The typography is right, the photography is color-managed, and the order of the projects was argued over for weeks. It is also too large to travel by email, so every inquiry gets a cloud storage link instead. The client then has to download the file, open it, and find the work that resembles their own job before they can reply with anything more than a polite thank you.
A PDF portfolio is a file a client has to download, open and keep track of; a portfolio website is an address they can open on a phone, forward to a colleague and return to a week later. The deck holds its ground where an application system demands an upload and where the layout must not reflow. It gives way wherever the work has to be found, read in the order that suits the reader, or passed to somebody who was not on the original email. For most people the sensible arrangement is to send a link and keep a current export for the few places that ask for a file.
That is the argument in one paragraph. The rest of this piece is about the cases in between: what a client does in the first minute, what they do when they want the third project rather than the first, and which of the two formats survives being forwarded twice.
Portfolio website or PDF portfolio: the short answer
Send the link. Keep the file.
For most designers, photographers, architects, studios, and freelancers of any discipline, the default should be a portfolio website — a plain address that fits in an email, a signature, a proposal, or a message — with a current export kept on hand for the small number of places that insist on a document. That is not a reluctant compromise. It is the arrangement that matches how creative work is read now. Inquiries arrive on phones. Decisions involve more than one person. The person who commissions the work is very often not the person who first saw it.
The reverse arrangement — a PDF as the primary artifact, with a website kept vaguely current "when there is time" — is the common one, and it is the source of most of the friction described below. If you are unsure what the website half of that arrangement needs to contain, what a portfolio website is and what belongs on one sets out the parts.
What a client sees in the first thirty seconds
Picture the moment the portfolio is opened. It is rarely a studio visit. It is a project manager at eight-twenty in the evening, on a phone, working through the four replies to an inquiry she posted last week.
The deck asks her for a decision before it shows her anything. Download this file. A file too large to email means waiting on a home connection, and over cellular data it eats into her data plan. When it opens, the phone's PDF viewer renders page one at whatever zoom it chooses, which is usually the width of a landscape page squeezed into a portrait screen. The type is a fraction of an inch tall. She pinches, drags, and arrives at page two.
The link asks her for nothing. The page loads, the first three projects are on screen at a size her eyes can use, and within a few seconds she has formed the judgment that the whole document was assembled to produce. If she likes what she sees, she is already one tap from the project that matters to her. If she does not, she has cost herself six seconds rather than a download.
Neither format wins on the strength of the work. They differ on how much friction sits between the client and the first honest look.
How a client moves between projects, and where they stop
A deck is a sequence. A website is a map.
That difference matters more than it sounds, because a client almost never wants your sequence. They want the two projects that resemble their own job. If your deck opens with your best project and those two sit near the back, the client has no way of knowing they exist without scrolling past pages that are not for them. They may well stop long before they reach them.
On a portfolio site the same client sees a filter, a set of labels, or just an index of twelve project titles with a line of context under each. Healthcare, retail, residential, hospitality. They are inside the relevant work in one tap, having skipped nothing they wanted.
The stopping point is the thing to watch. With a deck, a reader can stop early and never learn what came later. With a site, they stop when they have seen enough of the right thing — which is a different and much more useful kind of stopping.
How much of each project to show, and in what order
A flat document forces one depth of detail on every reader. Give each project six pages and the deck reaches ninety pages, which nobody finishes. Give each project one page and the work looks thin, because a single hero image cannot carry a nine-month renovation.
A site lets the two audiences coexist. The index page carries twelve projects, each with one strong image, the client type, and a single line of outcome — a 340-seat restaurant reopened in eleven weeks is worth more than a paragraph of adjectives. The reader who wants depth taps through to a project page that runs to fourteen images, a short account of the brief, the constraint that made it difficult, and what the client got. The reader who wants a quick impression never has to scroll past it.
This also fixes the ordering problem. In a deck, the order is a permanent decision made once for every reader. On a site, the order can be revised whenever your work shifts, and a project can be promoted to the top for a season without rebuilding the whole layout.
Work a flat file cannot carry: motion, sound, working builds
Some work does not survive being printed to a page.
A motion designer's showreel becomes three stills and a note reading video available on request, which is a request most clients will not make. A sound designer's portfolio becomes a track listing. A furniture maker's turntable render becomes one angle. A web designer's responsive layout becomes a screenshot at one width, which is the one property of the work that mattered.
A portfolio page holds the video inline, plays the audio where the reader is standing, and, in the case of software or product work, can hold the working thing itself rather than a picture of it. That last case is worth stating plainly, because it is where a portfolio stops being a document and starts being something a client can use. We have written elsewhere about the shift from static pages to applications that do something; a portfolio with a live calculator, a configurator, or a working prototype embedded in it is a small instance of the same shift.
Being found: search, referrals and the introductions you do not see
A PDF in a cloud folder is invisible. Nobody has ever found a designer by searching for a file sitting behind a sharing link. The deck only ever reaches the people you personally send it to, which means the ceiling on your inquiries is the number of emails you write.
A portfolio site is searchable, and each project page is its own point of entry. A studio with twelve project pages has twelve chances to be found by somebody describing the job they need doing rather than the person they need to hire.
The larger effect is the one you never observe. Work gets recommended sideways: a former client pastes a link into a group chat, a procurement officer forwards an address to two colleagues, an editor drops it into a message thread while a shortlist is being drawn up. Every one of those transfers is a single line of text. The same transfer with a deck requires somebody to find the file, check it is the current version, and attach a large file to an email they were not planning to write. Often they just say the name and move on, and the introduction quietly does not happen.
Where the deck still wins: upload forms, fixed layouts, offline review
There are real cases where a file is the right answer, and pretending otherwise helps nobody.
Submission systems that demand an upload. Award entries, vendor applications, public bids, grant programs, and many hiring portals accept one PDF, often under a stated size, and offer no field for a URL. The file is not optional there.
Layouts that must not reflow. A spread designed as a spread — a typographic study, an editorial layout, a printed piece shown as it was printed — needs fixed pagination. A page that reflows on a narrow screen is not showing that work honestly.
Rooms without a connection. Judging panels, job-site trailers, airplanes, and client offices with hostile guest Wi-Fi are all places where a file on a laptop works and a link does not.
A record of what was sent, on a date. For competitive submissions there is value in a frozen artifact. A live site is current by design, which is usually the point, but it means you cannot later show exactly what the panel saw in March.
Deciding case by case which one to send
A short set of rules covers nearly every situation.
If a form asks for a file, send the file. If a person asks for your work, send the link. If the inquiry arrived on a phone, the link is the only sensible answer. If the recipient is likely to forward it to two colleagues you have never met, send the link, because that is the transfer the file will not survive. If the work is motion, sound, or interactive, send the link and do not apologize for it. If the submission will be judged on a printed spread, send the file and make it beautiful.
And when a client asks for "your PDF" out of habit, the polite answer is both: the link in the sentence, the file attached underneath. You lose nothing by giving them the choice.
Keeping a link and a file without maintaining two portfolios
The reason many studios end up with a stale website and a heavily-worked deck is that maintaining both, separately, is a job nobody has time for. Two sets of images, two project orders, two places for a typo to survive.
The fix is to keep one source and let the two outputs come from it. Many studios already have the material for it: the PowerPoint or Keynote deck the portfolio has been living in for years. That file can be the starting point for a portfolio site built from the deck you already have, with each project on a page of its own rather than a slide in a sequence. The upload is a snapshot, so from then on the site is the source you edit, and the PDF is brought up to date from it when a form asks for one. The same applies to a general company deck rather than a project portfolio, which becomes a site rather than a slide sequence.
If you are starting from a folder of images and project notes instead, publishing a portfolio without building a website by hand is the shorter route. Either way, the working rule is the same: update in one place, publish, and let the file be the derivative rather than the original.
The change is small, and it is not about format. It is that the next time somebody asks a colleague who designed that space?, the answer can be one line of text that opens on a phone, works on the third forward, and shows the relevant projects first to the person who came looking for them.
