How to Request a File From Someone (Without Making Them Sign Up)

Every file-sharing tool is built around pushing a file outwards: you have something, you send it. A file request runs the same machinery backwards. You publish an empty container and someone else fills it.

That sounds like a small distinction until you look at who has to do the work. When you send someone an upload link instead, they need to find a tool, decide which one, sign up for it, and hope the resulting link is not blocked by your mail filter. With a request, all of that has already been decided by you. The person on the other end opens a page and picks a file.

• They need no account. No signup, no email verification, nothing installed. Only you verify an email, because the files become yours.
• The rules travel with the request. How many files it will take, how large, whether they must be encrypted, and when it closes — all fixed before anyone uploads.
• It closes itself. A request stops accepting uploads when it is full or when it expires, so a link you sent in March is not still open in November. Closing stops new uploads; the files already submitted stay until the request expires or you delete it.

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.

Why a request fits: 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.

Why a request fits: 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.

Why a request fits: 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.

Why a request fits: 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.

Why a request fits: It is a web page. Nothing is installed and no account is created on their side.

Where a request is the wrong tool

• 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.

Ask for a file in under a minute. The person sending it needs no account and nothing installed.

Both modes collect files. They differ in whether you know, in advance, who is sending.

The tracking row is the one that decides it in practice. A link tells you three files arrived; invites tell you that Dana and Sam delivered and Alex did not, which is the thing you actually needed to know on Friday afternoon.

Codes are single-use by design. Once someone's file lands, their code stops working, so a forwarded invite cannot quietly become a public upload endpoint. If an upload fails or is abandoned, the code is released so that person can try again.

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.
2. Describe what you need — A title and optional instructions, both shown on the upload page and in the invite email.
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.
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.

What the other person sees

1. Open the link — No account, no signup, no app. If they were emailed an invite, their code is already filled in.
2. Choose one file — Within the size limit the requester set. The page says what that is before they pick anything.
3. Send — If the request asks for encryption, it happens in their browser before the upload starts.

Their whole interaction is three steps long, and none of them involve creating an account.

A request often carries exactly the material you would least like a third party to hold: an unreleased cut, a manuscript, a signed contract, source code. So encryption is a per-request setting with three positions.

Off

The file is stored as-is. Our servers can read it, the same as any ordinary upload.

Who can read the file: 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.

Who can read the file: 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.

Who can read the file: You, once they tell you their passphrase. Not us.

When encryption is on, the file is encrypted with AES-256-GCM with Argon2id key derivation inside the sender's browser before a single byte is uploaded. What reaches our storage is ciphertext we hold no key for.

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.

There is a specific reason the passphrase is never in the invite email: we compose those emails on our servers. Putting a passphrase in one would hand our own infrastructure the key that the encryption exists to withhold, which would make the whole exercise theatre. So you share it yourself — by chat, by phone, in person — and we genuinely never see it.