Delete a shared image when you are done with it

A share link is unlisted, but it is not secret. Nobody can guess it and search engines don't index it. Still, once you post that URL in public, or the person you sent it to passes it on, anyone with the link can open the image. That is when you delete a shared image. The delete button takes it offline and closes the loop.

How to delete a shared image

Open the share URL in any browser. The image shows on the left, and the share controls sit on the right. You will see the URL, the Copy link button, and a Download button. The delete control is on the same page, usually just under the URL row. Click it, confirm the prompt, and the request goes to storage.

What actually happens when you delete

1. The delete request goes to the imagepaste edge API.

2. The R2 storage entry is removed within about a minute.

3. The share URL starts returning a 404 response on the next fetch.

4. The 12-character ID is retired, so it is never reused for a future upload.

Cached copies matter. If the image was hot-linked into a Slack message, a forum post, or a blog, those viewers may see a cached version for a few minutes until their CDN or browser cache expires. Usually this is 5 to 10 minutes. After that, all requests hit the 404.

Deletion is permanent. There is no trash or undo, and no second copy on the server.

What if I lost the share page?

For an anonymous upload, the share URL is the only handle. There is no history list tied to your identity, because the site does not know who "you" are. Uploads made while signed in are different: they appear in your dashboard, so you can find and delete them there even if you lost the original link.

In practice, the share link lives in three places:

• Your browser history for the session. Search it for "imagepaste".

• Wherever you pasted the link, such as Slack, a ticket, or the email thread.

• Your clipboard manager, if you use one. Raycast, Maccy, and Clipy on macOS all keep your recent clipboard entries.

If all three are gone, the upload is stuck at whatever random ID it was assigned. It will still not be indexed or guessable, and still only reachable by someone who has the exact 12-character string. But it will also not be deletable until you find that string again.

Preventing the problem

Two small habits keep this from ever becoming a problem.

1. Bookmark the share page for anything you might want to delete later. A single bookmarks folder called "uploads" covers it.

2. Keep the delete tab open for high-stakes uploads (a dashboard with customer data, a screenshot from a paid-for app). Close it only after you have confirmed the recipient has what they need.

Delete now or let it expire: the 7-day rule

Anonymous uploads take care of themselves eventually. Seven days after upload, the file is removed from storage automatically and the link starts returning a 404. If the screenshot was routine, a build failure, a settings panel, a meme, waiting out the week is a perfectly fine plan.

Sensitive content should not wait. A dashboard with customer emails, or an API key caught in a terminal, deserves a manual delete the moment the recipient has seen it. Seven days is a long time for something you would not want forwarded.

Signed-in uploads never expire on their own. That is the point of signing in: links you put in documentation or a README keep working. The trade is that cleanup is manual, from the dashboard, whenever a link outlives its purpose.

Deleting from the dashboard

If you were signed in when you uploaded, you do not need the share link at all. Open your dashboard and every upload tied to your account is listed with its preview and URL. Find the image, use its delete control, confirm, and the same removal sequence runs: storage entry gone within about a minute, link returning 404 after the cache clears.

This is the safety net for the lost-link problem above. It only covers uploads made while signed in, though. Anonymous uploads stay anonymous, to you and to the site both, so for those the share page remains the only door.

Rate limits on deletion

There is no special limit on deletions. They go through the same edge as regular API calls. If you paste a link and want to remove it immediately, that works. The only caveat is that cache warmup can mean the image is briefly visible at a CDN node after the storage delete has completed. For sensitive uploads, wait a few minutes for the cache to expire before assuming the image is truly gone.

What deleting cannot undo

Deleting removes the file from imagepaste, but it cannot reach copies that already left the site. If someone opened the link and saved the image, or took a screenshot of it, that copy is theirs and stays on their device.

The same is true if a chat app or social platform re-hosted the image on its own servers when you pasted the link there. Delete early if the image is sensitive, but treat anything you have already shared widely as out of your hands.

Tutorials that go with this one

The Ctrl+V paste guide and the crop guide cover the upload side. The mobile guide covers the phone flow. Delete is always the same regardless of how the upload was created.

Conclusion

A signed-in upload stays live until you remove it, and an anonymous one is removed automatically after 7 days, so deleting by hand is still the step that matters when the content is sensitive. Nothing private should wait out the clock. That part is on you, and it only takes a moment.

The simplest thing you can do is bookmark the share page the moment you upload something you might want gone later. When the time comes, open that page, hit delete, confirm, and the link is dead within a minute. If the upload held anything sensitive, give the cache a few minutes to clear, then check that the link returns a 404. Once it does, the image is gone for good.