How to Share Large Files Privately
A private share needs four things: no account to open it, no search-engine indexing, a download that is byte-identical to the original, and a way for the sender to revoke it. On an 18 MB test upload, the stored size matched the source exactly (18,874,368 bytes) and the re-downloaded file's SHA-256 was identical.
Measured Data
| Measurement | Result | What it proves |
|---|---|---|
| File size | 18.0 MB (18,874,368 bytes) | just under the 20 MB free-tier cap |
| Upload time (local loopback) | 75 ms / 240.3 MB/s | streamed to disk, not buffered in memory |
| Stored size vs source | identical, byte count preserved | no server-side conversion |
| Preview page weight | 1,056 bytes of HTML in 16 ms | the recipient loads a page, not the file |
| Download time (local loopback) | 118 ms / 152.1 MB/s | direct file response, no proxy hop |
| SHA-256 source vs downloaded | identical | byte-for-byte integrity, verified |
| Main domain /f/ response | 302 to the isolation domain | content is not served from the brand domain |
| Isolation domain headers | X-Robots-Tag: noindex, nofollow | not indexable, enforced per response |
| Isolation domain robots.txt | User-agent: * / Disallow: / | crawlers refused site-wide |
| Manage page without owner token | 404 | management surface is not discoverable |
Four Things that Make a Share Actually Private
Privacy in file sharing gets discussed as if it were one setting. It is four independent properties, and most tools get two or three:
| Property | What it means | How to check it |
|---|---|---|
| No account required | the recipient opens it in one click | try the link in a private window |
| Not indexed | search engines cannot surface the content | fetch robots.txt on the host serving the file |
| Byte-identical | the file arrives as you sent it | hash both ends |
| Revocable | you can end access before it expires | look for a delete control |
A link that satisfies three of these is not private in any useful sense. An indexed file that cannot be deleted is a permanent public copy. A revocable file that gets silently re-compressed breaks whatever the recipient needed it for.
Why the File Domain Is Separate
The strongest structural decision in this design is that shared files are not served from the brand domain. The short link on filesq.link responds with a 302, and the content is delivered from a separate isolation domain whose only job is to hand back a file.
That separation buys three things:
Indexing is contained. The isolation domain returns X-Robots-Tag: noindex, nofollow per response and serves a blanket Disallow: / in robots.txt. Both were verified on a live upload rather than taken from documentation. If a shared file were ever flagged as problematic, the reputational blast radius lands on a domain that hosts nothing else — not on the site your visitors arrive at.
The brand domain stays clean. Search engines never see user-uploaded content under the same hostname as your marketing pages. There is no path by which a shared archive influences how filesq.link is understood.
The cookie and header surface is minimal. The isolation domain only serves file pages, downloads and static assets; every other path returns 404. There is no logged-in area to attack, because there is no login there at all.
Byte-Identical Delivery Is a Checkable Claim
"Your files are never modified" is the kind of sentence every service writes and nobody verifies. It is verifiable in one step:
- Hash the file before uploading —
sha256sum photo-archive.zip. - Upload, copy the short link.
- Download it again from a different machine.
- Hash the download.
The hashes match or they do not. On our 18 MB measurement they matched, which is expected: the upload handler streams request chunks straight to disk and the download handler returns that file path directly. There is no image pipeline, no transcoding step and no "optimisation" pass in between. For an archive of source code, a game build or a set of design assets, that is the property that matters — a single altered byte invalidates a signature.
One honest caveat: because nothing is inspected, nothing is inspected for you either. If you send an archive, the file arrives as an archive and the recipient does the unlocking. We do not scan contents, which also means we cannot warn you about what is inside.
Revocation, and What It Does Not Do
Every upload returns a manage link carrying an owner token. That page shows per-day views, unique visitors and downloads, and it has a delete button that breaks the public URL immediately.
What it does not do is un-send the file. If someone already downloaded it, deleting the link removes your copy and the hosted URL — not theirs. Anyone who can view an unlisted link can forward it. Treat the manage link as the control for retention, not as a retraction mechanism.
Matching the Tool to the Job
| Situation | Right approach |
|---|---|
| One file to a few known people, short window | unlisted link; delete when done |
| Sensitive document to one recipient | unlisted link plus an encrypted container the recipient can unseal |
| Archive that must not change | any host that preserves bytes — verify with a hash |
| Material that must not be indexed | confirm the host serves noindex headers, do not assume |
| Something you may need to retract | link plus a stated expiry you actually enforce |
The last row is the one people skip. A link with no expiry and no delete control is a permanent publication, whatever its privacy settings claim.
Run it on your own file
This page explains the mechanism. The tool applies it — nothing is uploaded.
FAQ
Is an unlisted link the same as a private link?
No, and conflating the two is the most common mistake. An unlisted link is not indexed and not discoverable, but anyone who obtains the URL can open it. A private link requires authentication, which also means the recipient needs an account. Filesq gives you unlisted; if you need access control, use a link plus a separate channel for the key.
Can search engines index my file?
Not on filesq.link, and not on the file domain either. Content lives on a separate isolation domain that returns X-Robots-Tag: noindex, nofollow on every response and serves a robots.txt with a blanket Disallow. We measured both on a live upload — they are response headers and a served file, not policy language.
Does the recipient's download match what I uploaded?
It matches byte for byte. We hashed an 18 MB archive before upload and after download: identical SHA-256. Nothing is re-encoded, transcoded, watermarked or appended. That matters most for archives of code, game builds and design assets, where a single changed byte breaks the payload.
How do I delete a file before it expires?
Every upload returns a manage link containing a one-time owner token. Opening it shows the view and download counts and a delete button. Accessing the manage path without that token returns 404 rather than a permission error, so the existence of a management interface is not disclosed.
What is the practical size limit?
20 MB per file on the free tier, with 3 new links per day, 500 views per link and 3 days of retention. A full 18 MB upload measured 75 ms (240 MB/s) against a local server — the real constraint for most senders is upstream bandwidth, not the app.