Privacy

Mubifiles has no accounts, no analytics, no advertising and no tracking cookies. This page describes what the service actually does with what you send it. It is written from the implementation rather than from a template, so where it is vague it is because the answer is genuinely uncertain, not because we are being careful with words.

What we store

While a session is open, we hold two things.

• The files you upload. Stored as opaque objects. The storage path contains no filename and no session code — it is built from two random identifiers. The original filename is kept separately so the other device can save it under the right name. Limits are 1 GB per file and 3 GB per session.

• A session record. The six-digit code, when the session was created and last used, which of the two devices sent each item, and the text of any text you share. Text is small, so it lives in the session record rather than in file storage.

Access to a session requires a token issued when you create or join it. We store only a hash of that token, not the token itself.

Files sent directly are not stored at all. When both devices are on the same network you can send a file straight from one to the other. Those bytes never reach us — there is no upload, no object, and nothing to delete afterwards. What we do hold for that is the short handshake the two devices need in order to find each other, which lives in the session record and goes when the session does. The other device sees it — that is what makes the direct connection possible. What is in it depends on your browser; the IP addresses section below says what we measured.

How long we keep it

A session closes about 15 minutes after the last activity, and in no case later than 24 hours after it was created. Using the session pushes the 15-minute window forward; the 24-hour limit never moves.

When you end a session yourself, the files and the session record are deleted immediately. Otherwise the session record expires on its own, and a cleanup job that runs every fifteen minutes removes any files whose session has gone. Deletion is not something we choose to do on request — it is how the service is built.

There is no archive, no backup you can be restored from, and no way for us to recover a session once it has closed.

IP addresses

IP addresses are used only to limit how much any one network can send. They appear in two kinds of counter — one that expires within a couple of minutes, and one that records a running total of bytes uploaded and expires within a day — and never against a session, a file, or a particular upload. We keep no record of what was sent from an address, only how much.

Exactly what that means

Most endpoints are rate-limited with a counter held in Cloudflare KV. The address forms part of that counter's key — literally written down, alongside which limit it counts and which time window it belongs to. The key is set to expire 120 seconds after it is written, and is discarded then. We never read these keys for any purpose other than deciding whether to allow the next request.

The session-state endpoint, which your browser polls while a session is open, uses Cloudflare’s own rate-limiting service instead. Your address is passed to it as a key; nothing is stored on our side at all.

There is also a daily cap on how much one network can upload. That counter is kept for up to 25 hours — long enough to cover the day it counts — which makes it the longest-lived thing here derived from an address. It is not keyed on the address itself: the address is put through a keyed hash using a secret we hold, so the stored key cannot be turned back into an address by anyone who obtains it. What it holds is a number of bytes and nothing else — no filenames, no session, no record of what any of those bytes were.

In none of these cases is the address written into the session record, attached to a file, or kept anywhere that would let it be matched to something you sent. There is no join to make.

Sending a file directly between two devices adds one more thing to the session record, and it is worth being exact about what it is. Each device writes a short description of how the other can reach it, which we pass along and hold for as long as the session lasts. In Chrome we have checked what that description contains: the device’s address on its own network is replaced by a random name ending in .local, generated by the browser, so no address of yours appears in it. That name stays the same for the tab that made it and differs between tabs. We have not been able to test other browsers, and a browser is free to put a real local address there instead — so treat this as what we observed in one browser rather than a promise about all of them. Either way it describes only your own local network, never the address we see you from, it is used for no limit or counter, and none of it exists unless you choose to send a file directly.

Separately, our hosting providers below receive your IP address as part of ordinary web traffic and keep their own request logs under their own policies. We do not control those logs and do not consult them.

What your browser stores

We set no cookies. These values are kept in your browser’s local storage and never sent anywhere except as part of using the service:

mubifiles.session

The six-digit code of your current session and the token that authorises this device to use it. So refreshing the page does not lose the session. Cleared when the session ends.

mubifiles.uploads

For a large file being uploaded: its name, size and the identifiers of the pieces that have already been sent. So an upload interrupted by a dropped connection or a closed tab resumes instead of starting over. Cleared when the upload finishes or the session ends.

mubifiles.theme

Your light or dark theme preference, if you have set one. So the page does not flash the wrong theme on load.

The site also installs a service worker, which keeps a cache on your device so it opens without a connection. A copy of the pages, scripts and images that make up the site, so it still opens when you are offline. Nothing you send or receive is in it. Files and text go straight to the server and are never written to this cache — it holds only the site itself, the same files anyone downloads by visiting.

Clearing site data in your browser removes all of it, the cache included.

What we do not do

• No accounts, so nothing is tied to an identity.

• No analytics, no advertising, no third-party scripts of any kind. The pages load nothing from outside our own domain.

• No tracking cookies. No cookies at all.

• No selling or sharing of anything you send. The providers listed below process it to run the service and for nothing else.

• No scanning or reviewing of what you send, except when acting on a specific report.

Who processes your data

Mubifiles runs on two providers. Both may process data outside your country.

Vercel

Serves the website itself — the pages and scripts your browser loads. Vercel receives the requests your browser makes for those files.

Cloudflare

Runs the API (Workers), holds session records (KV) and stores uploaded files (R2). Everything you send passes through and is stored by Cloudflare until it is deleted.

Security, honestly

Traffic is encrypted in transit, and files are stored encrypted at rest by our storage provider. But we can read what you send, because we hold the key material — this is not end-to-end encrypted. Anyone who obtains a session code within its short lifetime and gets past our rate limits could join that session. Do not use Mubifiles for anything you would not be willing to lose control of.

Your rights, and their limits

Because there are no accounts, we hold nothing that identifies you, and so there is usually nothing for us to look up, export or delete on request. If you want something removed before it expires, end the session — that deletes it immediately. To have a specific file removed, see reporting abuse, which explains what we need in order to find it.

Mubifiles is not intended for children, and we have no way to verify anyone’s age.

Changes and contact

If how the service handles data changes, this page changes with it. Questions go to abuse@mubifiles.com, which is the same address used for abuse reports.