Best Way to Request Files From Clients
There is no single best way to request files from clients — the right pick depends on how many items you need, how often, and whether any of it is a password.
Why "just send me the files" stops working
For a one-off request — three photos, a single PDF — almost any method works, because there is nothing to track and nothing to forget. The trouble starts once a project needs more than a handful of things, from someone who is not thinking about your project between the moment they read your email and the moment they remember it exists again.
At that point the format you chose starts to matter more than the request itself. No visible progress means you cannot tell what is still missing without re-reading an old thread. No reminders means the second ask depends entirely on you remembering to send it. No structure for anything but a file turns "and also, what are your opening hours" into its own separate, easily lost message. And treating a hosting password the same as a logo photo puts a credential somewhere it should never sit for long: a plaintext message in two inboxes, indefinitely.
The five approaches below solve different slices of that problem. None of them is wrong; each is a reasonable choice for a certain shape of project.
The five approaches, compared
Email attachments
Ask for what you need in the body of an email and let the client reply with attachments or paste answers inline.
Good at: zero setup, works for literally anyone, and it is the format every client already trusts and checks daily. For a single item or two, it is genuinely the fastest option — there is no faster place to say "can you send the logo" than an email you are already writing.
Where it breaks: there is no per-item state. A thread with six replies mixes what has arrived with what hasn't, and confirming "did I get everything" means scrolling back through the whole conversation. Nothing reminds the client if they forget, so the second ask is on you, and it usually comes later than it should. File size is capped by the mail provider, so anything beyond a few photos bounces or gets rejected silently. And a password sent this way sits in plaintext in the client's sent folder and yours, in every backup of both, long after the project is done.
File-transfer links
A one-time link — the kind you generate from a transfer service and send by email or chat — that lets someone upload a batch of files without an account, usually with an expiry date.
Good at: large files that email would reject: raw photo sets, video, a full site backup. No account needed on either side, and most services notify you the moment something lands.
Where it breaks: it collects files and nothing else — there is no field for "what are your business hours" or a structured yes/no. It is a single upload event, not a checklist, so there is no sense of "3 of 8 done." Most free tiers expire the link and delete the files within days, which is a problem if the client takes two weeks to get around to it. And like email, there is no reminder mechanism baked in — you resend the link by hand, or the client misses the deadline and starts over.
Cloud-drive file requests and shared folders
Two close cousins from the same category: a "request files" feature built into a cloud-drive product, where anyone with the link can upload without an account, or a folder you share directly with the client's own account for ongoing back-and-forth. Dropbox's version of this is covered item-by-item, with sourced numbers, in BriefGate vs Dropbox file requests.
Good at: it fits naturally if your team already lives in that cloud drive, since the files land exactly where you would have filed them anyway. A shared folder in particular is good for an ongoing project where new files trickle in over months, not a fixed list collected once. Branding and a deadline are available on paid tiers of most of these products.
Where it breaks: a file request collects files only — the same structural gap as a transfer link — and a shared folder has no structure at all; it is a directory, not a checklist, so nothing stops a client from dumping unrelated files in or missing one entirely. Neither option handles credentials, and a shared folder specifically requires the client to have or create an account with that provider, which is exactly the kind of extra step that stalls a non-technical client.
Form builders
A form with fields you design — some text, some file uploads, maybe a dropdown — built in a general-purpose form tool and sent as a link.
Good at: structure. Unlike the three options above, a form can ask for a mix of files, short answers, and choices in one place, and a completed form is a single readable record rather than a scattered thread. Good for one-time collection of a known, fixed list.
Where it breaks: most form builders are built for a single submission event, not an ongoing checklist — closing the tab usually means starting over. File-upload fields tend to have small size caps well below what a photo gallery or video needs. Validation is typically limited to "required or not," so a logo that is 200 pixels wide sails through as easily as one that is 2,000. And a form field is not an encrypted credential store — a password typed into a generic form field is stored exactly as durably as everything else in that backend, which was not built for holding it.
Dedicated client intake portals
A tool built specifically for this problem: you define the list of items the client owes, the tool builds them a branded, no-login page, and it chases them on a schedule until the list is done. BriefGate is one example of this category, alongside human-run tools like Content Snare — see BriefGate vs Content Snare for how a portal built for an AI agent differs from one built for a project manager.
Good at: everything the other four approaches lack in combination — typed items instead of a folder of files (a file is different from a yes/no, which is different from a structured set of opening hours), visible per-item progress the client can see and you can check without re-reading a thread, automatic reminders that mention only what's still outstanding, and — where the tool offers it — an encrypted, one-time-reveal path for credentials instead of a plaintext message.
Where it breaks: it is more setup than firing off an email, and it is not the right tool if you only ever need one file from one person one time — that is what a transfer link is for. It is also its own subscription or account to manage, which is overhead you should not take on for a single small project.
Which approach fits your project
| Situation | Best fit |
|---|---|
| One or two files, once, no follow-up needed | Email attachments |
| A single large batch of files (photos, video, backups) | File-transfer link |
| Ongoing files from a project that already lives in your team's cloud drive | Shared folder or cloud-drive file request |
| A fixed, known list of mixed files and short answers, collected once | Form builder |
| A recurring project type (website builds, onboarding, an e-commerce build) with more than five or six items | Dedicated intake portal, ideally from a saved template |
| Any credential — a password, an API key, a hosting login | A tool with an encrypted, one-time-reveal secrets flow, not email or a generic form field |
| A client who reliably forgets and needs following up more than once | Anything with built-in, scheduled reminders — rules out email and transfer links |
Number of items and need for reminders tend to move together: past six or seven distinct things, keeping track by memory or by re-reading a thread stops being reliable, and that is usually the same point where a client needs more than one nudge to finish.
Migrating from "email me the files"
If your current process is an email with a list in it, the move to something more structured does not have to happen all at once.
- Write the list out as discrete items first, independent of the tool. "Assets" becomes a logo, five photos, and a paragraph of copy — three things, not one. This step alone, done inside your existing email, already fixes some of the confusion, because a numbered list is easier for a client to work through than a paragraph.
- Separate anything that is a credential. Move it out of the email entirely — a password manager's one-time-share link is a minimum viable fix, and an encrypted vault with a one-time reveal is the more durable one. This is the highest-value single change, because it is the one item type where the plaintext-email default is a real, not theoretical, risk.
- Move to a link-based method once the list is genuinely too long for a thread to hold cleanly — usually somewhere past five or six items, or as soon as you notice yourself re-reading old emails to check what's still missing.
- Automate the follow-up last. A schedule that reminds a client about only what they haven't sent yet is the part manual processes give up on first, because tracking per-item status for several live clients by hand does not scale — it is also the easiest part to hand to a tool once the list itself is already structured.
The order matters more than the destination: a well-organized email list beats a disorganized portal, and the structure in step 1 is what makes every later step easier.
Where BriefGate fits
BriefGate is one implementation of the fifth approach above: your AI coding agent, or you from the dashboard, declares the list of items — including which are files, which are structured facts, and which are credentials — and BriefGate builds the client a single branded portal, chases them on a schedule, and hands the results back as typed data rather than a folder to sort through by hand. See item types for the full range it can collect, and the secrets vault for how it handles the credential case that email and shared folders both leave exposed. It is not the right pick for a single file from a single person — for that, one of the simpler approaches above will do the job faster. Learn more at BriefGate.