How to request a file from someone
The full walkthrough: links vs invites, encryption modes, and use cases.
Incoming Transfers
Ask someone to send you a file.
No account for them.
A file request turns the transfer around: instead of sending a file, you ask for one. The person you ask needs no account and no software — they open a link, choose a file, and it lands in your GetFileShare inbox.
What They See
Three Steps, No Signup
STEP 1
Open the link
No account, no signup, no app. If they were emailed an invite, their code is already filled in.
STEP 2
Choose one file
Within the size limit the requester set. The page says what that is before they pick anything.
STEP 3
Send
If the request asks for encryption, it happens in their browser before the upload starts.
Setting One Up
How to Request a File
Everything on your side takes about a minute, and nothing on theirs needs an account.
STEP 1
Verify your email once
The request is tied to a verified address. It is where submissions are announced and the only address that can open them.
STEP 2
Describe what you need
A title and optional instructions, both shown on the upload page and in the invite email.
STEP 3
Choose a link or named invites
A shareable link with a submission limit, or up to a handful of people who each get a single-use code.
STEP 4
Collect and download
Each arrival is emailed to you unless you turn notifications off. Open the request to download, decrypting in your browser if a passphrase was used.
Two Ways to Ask
A Link, or Named Invites
01OPEN
Shareable link
One link, a submission limit you set. Post it in a channel, put it in a brief, or paste it into a chat. Anyone holding it can upload until the limit is reached.
Open calls, a team drop-box, anywhere you do not know the names in advance.
02SINGLE-USE
Email invites
Each recipient is emailed their own single-use code. The code stops working the moment their file arrives, so one invite can never become a public upload endpoint.
A named list of people, and knowing exactly who has delivered and who has not.
Use Cases
What People Use It For
Freelancers delivering to a client
A designer has a final logo pack for a client who does not want to create an account anywhere, and neither party wants the file sitting in an inbox forever.
The client sends one link with a limit of one submission, so it closes itself the moment the file lands.
Agencies collecting assets
A campaign needs logos, brand fonts, and copy decks from four different people at the client, all of whom will otherwise reply-all with 40 MB attachments.
Four named invites, four single-use codes, and a list showing who has delivered and who is still holding things up.
Confidential or copyrighted material
A contractor is sending an unreleased cut, a manuscript, or source code that must not be readable by the platform carrying it.
Encryption is required on the request, the passphrase is agreed out of band, and the storage holds nothing but ciphertext.
Onboarding paperwork
A new contractor owes a signed contract and an ID scan, and the person collecting them does not want either sitting in a shared mailbox.
One invite per person, and an expiry date that deletes the files for good when it passes.
Anyone who cannot install software
The person sending the file is on a locked-down work laptop, a borrowed machine, or a phone.
It is a web page. Nothing is installed and no account is created on their side.
When to use something else
- Sending a file to someone — that is Cloud Share, or a direct transfer.
- Collecting many files from one person in one go. A submission is a single file, by design.
- Anything that has to be recoverable after the request expires. Expiry deletes the files permanently.
Confidentiality
Who Can Read the File
| MODE | HOW IT BEHAVES | WHO CAN READ IT |
|---|---|---|
| Off | The file is stored as-is. Our servers can read it, the same as any ordinary upload. | You, and us. |
| Required | You choose one passphrase and give it to the people you are asking. Their browser encrypts with AES-256-GCM with Argon2id key derivation before a single byte is uploaded, so what reaches our storage is ciphertext we hold no key for. | You, and anyone you gave the passphrase to. Not us. |
| Submitter's choice | Each person decides for themselves and picks their own passphrase, which they must send to you directly. Useful when the sender — not you — is the one who considers the file sensitive. | You, once they tell you their passphrase. Not us. |
The catch, stated plainly: We never receive the passphrase — not in the invite email we send, not at upload, not ever. That is the point, and it is also the catch: if the passphrase is lost, the file cannot be opened by anyone, including us.
Compared
File Request vs the Usual Ways to Collect Files
How asking for a file through a request compares with the two things people usually do instead.
| File request | “Just email it to me” | Shared-folder upload link | |
|---|---|---|---|
| Sender needs an account | No | An email account | Often, depending on the service |
| Largest file | A cap you set per request | Around 25 MB | Your storage quota |
| Closes itself | Yes — when full or at expiry | No | Only if you remember to |
| Know who has delivered | Yes, per invited person | Search your inbox | Check file owners by hand |
| Sender can encrypt in their browser | Yes — optional or required | No | Not on standard consumer plans |
| Where the files end up | Your request, until it expires | Your inbox, indefinitely | Your storage, indefinitely |
FAQ
File Request Questions
No. They open a link, choose a file, and send it. No signup, no email verification, and nothing to install. Only you — the person collecting — verifies an email, because that is the address the files belong to.
A share link hands a file out; a file request takes one in. The request also carries the rules: how many files it will accept, how large, whether they must be encrypted, and when it closes itself.
No. Each emailed invite carries its own code, and a code stops working once that person's file has arrived. If their upload fails or they abandon it, the code is released so they can try again.
Only if the request does not use encryption. With encryption on, the file is encrypted in the sender's browser with AES-256-GCM with Argon2id key derivation before upload, and the passphrase never reaches us — so our storage holds ciphertext we have no key for.
It stops accepting uploads and the files submitted to it are deleted from storage permanently. Download anything you want to keep before then, or close the request yourself once you have what you need.
Yes, on email invites. The request lists every address you invited and marks which have delivered, so chasing people does not mean re-reading your sent folder.
Each submission is a single file, by design. If you need several from one person, ask them for a single ZIP archive, or use a shareable link with a submission limit high enough to let them upload more than once.
Yes. Closing it stops new uploads straight away while keeping what has already arrived until the expiry date. If you want the files gone too, delete the request instead — that erases every submission immediately.
Any file type, up to the size cap you set when you create the request. The upload page shows the sender that cap before they choose a file, so nobody waits through an upload only to be rejected at the end.
Guides
Go Deeper
Password protect a file before sharing
How in-browser encryption works, and how to share a passphrase safely.
Send large files without email
Why attachments fail on size, and what to use instead.
A private and secure file sharing checklist
What to look for in any service that handles your files — ours included.
Ready to ask for a file? Create a file request, or read the full GetFileShare guide first.