You hit "send," the progress bar fills, your friend gets the file. Done, right? Not quite. That file now exists as a copy on a computer you've never seen, governed by a retention policy you probably never read.

For most shares this is harmless. But if you've ever wondered whether that ID scan from 2021 is still sitting on some server - The honest answer is: it depends entirely on where you shared it. A chat app, a cloud drive, and an expiring-link service give three completely different answers.

This article follows your file's actual journey: where it physically lives, how long different services keep it, what "deleted" really means, and the questions worth asking before you upload anything sensitive.

Key takeaways

  • A single 50 MB upload can become three or four physical copies once a service replicates it to 2–3 extra disks.
  • Chat apps keep attachments effectively forever, cloud drives until you delete plus a 30-day trash window, and expiring services delete by default.
  • "Deleted" is a spectrum - From a 30-day trash folder up to cryptographic erasure, where the key is destroyed and leftover bytes stay unreadable.
  • ShareIt.onl deletes files from the server (not just unlinks them) when your 1-hour to 7-day timer runs out.

Where Your Upload Physically Lives

When you upload a file, it travels (encrypted by HTTPS) to a server - A real machine in a data center, writing your bytes onto SSDs or hard drives. Big services then typically replicate the file to 2-3 additional disks or locations so a hardware failure doesn't lose it. A single 50 MB upload can quickly become three or four physical copies.

The Copies You Forget About

Add the copies you don't think about:

  • The recipient's copy once they download it - On their laptop, phone, or both.
  • Cache copies on devices that previewed the file.
  • Backup copies, if the service snapshots its storage on a schedule.

The takeaway isn't paranoia - It's that "I shared a file" really means "I created several copies and gave up control of most of them." Which makes the next question the important one: how long does each copy stick around?

Retention: The Same File, Three Very Different Fates

Where you share determines how long the service-side copy lives. The contrast is stark:

Service type Default retention You must remember to delete? Typical example
Chat apps (email attachments too) Effectively forever - As long as the account/chat exists Yes, in every conversation copy A photo sent in a group chat in 2019 is still there
Cloud drives Until you delete it, plus a 30-day trash period Yes, and shared links often stay live A "temporary" folder shared in 2022, still accessible
Expiring-link services A fixed window, then automatic deletion No - Deletion is the default A link that stops working after 24 hours

Why Chat Apps Are the Worst Offenders

Chat platforms are the silent hoarders: every attachment in every conversation is retained indefinitely by default, searchable by anyone in the thread, forever. Cloud drives put you in control but bet on your discipline - And most people never audit old shared links. Expiring services flip the default: keeping a file requires action; deleting it requires nothing. That default is the whole argument in why expiring links are safer, and the broader trade-offs between the models are compared in cloud storage vs. direct file sharing.

What "Deleted" Actually Means

"Deleted" is a spectrum, not a switch. From weakest to strongest:

  1. Hidden from you. The file leaves your view but sits in a trash folder - Commonly restorable for 30 days.
  2. Unlinked. The service forgets where the file is on disk and the link dies. The bytes may linger until that disk space is overwritten - Usually quickly on busy systems, but not instantly.
  3. Purged from backups. Honest services state a window (often up to 30 days) for a deleted file to age out of backup snapshots.
  4. Cryptographic erasure. The file was stored encrypted and the key is destroyed, making leftover bytes permanently unreadable - The gold standard.

For practical purposes, once a reputable service unlinks a file and the link returns nothing, your realistic exposure is over: no one can request, browse, or search their way to it. The residual-bytes issue matters mainly for highly sensitive data - Which is why encrypting such files before upload (so the server only ever held ciphertext) beats relying on any deletion promise.

Tip: For truly sensitive files - Legal, medical, or financial - Encrypt them with AES-256 before uploading. Then the server only ever holds unreadable ciphertext, so you never have to trust any deletion promise.

Five Questions to Ask Any Sharing Service

Before uploading anything you care about, spend two minutes on the service's FAQ or privacy policy and check:

  • How long is my file stored, and can I control it? A number ("deleted after 24 hours") beats vague wording ("retained as needed").
  • What happens at expiry - Link disabled, or file deleted? These are different. You want the file gone, not just the pointer.
  • Do old links keep working after I "remove" a file? Some cloud shares survive the file being moved or renamed.
  • Is an account required, and what metadata is kept? Less collected means less to leak - Your email, IP logs, and sharing history are data too.
  • Are files scanned, indexed, or used for anything? The answer should be limited to malware scanning at most.

A service that answers these plainly, in numbers, is telling you it has nothing to hide. Vagueness is itself an answer.

How ShareIt.onl Handles It

Since we're asking every service these questions, here are our answers. ShareIt.onl is built expiry-first: you upload up to 10 files (200 MB total) with no account, choose a lifetime of 1 hour, 12 hours, 24 hours, 3 days, or 7 days, and get a short link and QR code. When the timer runs out, the files are deleted from the server - Not just unlinked - And the link stops resolving.

There's no library of your past uploads sitting behind a login, because there's no login. Uploads and downloads run over HTTPS, and links are random and unlisted, so the only people who can reach a file during its window are people you gave the link to.

In other words: the file's fate is decided the moment you pick the expiry, not left to whether you remember to clean up someday.

FAQ

Are my files stored forever after I share them in a chat app?
By default, yes - Attachments in email threads and chat conversations are kept as long as the conversation and accounts exist, which is often many years. Every participant's copy of the thread retains the file, so deleting it on your side rarely removes it everywhere.
Does an expired link mean my file is really gone?
On an expiry-first service it should mean the file itself is deleted from the server, not just that the link stopped working - Check the service states this explicitly. After deletion, backup copies typically age out within a stated window, ending any realistic exposure.
Can a service employee look at my uploaded files?
Technically, staff at most services *could* access stored files, though policies and access controls restrict it. If that possibility is unacceptable - For legal or medical documents, say - Encrypt the file with AES-256 before uploading, so the server only ever holds unreadable data.
Is my file safer on a service with no accounts?
In one specific way, yes: with no account, there's no logged-in library of everything you've ever shared waiting behind one password. Combined with automatic deletion at expiry, a no-signup service holds your file briefly and forgets it, instead of accumulating a history.