Plan for the day the link stops working
A temporary link is convenient because it cleans itself up, but anything that still points to it will break once the retention period ends. Decide where the link will live before you choose a duration.
- Keep the original file on your own device. The hosted copy is not a backup and cannot be restored after cleanup.
- Avoid temporary links in places people will read later, such as README files, wiki pages, published articles or product listings. They suit conversations and reviews that have an end.
- If a discussion runs longer than expected, upload the image again before the old link expires and post the new URL. The upload page has no option to extend an existing upload.
- Pick the shortest duration that covers the task. A 1-day link for a quick support reply leaves less material online than a forgotten 30-day link.
When the retention clock starts
Choose 1 day, 7 days or 30 days on /upload before you upload. The retention period is intended to start when the upload completes successfully and a hosted URL is created.
What expiry means in practice
- After the selected period, the hosted file is intended to become unavailable at the original URL.
- Expiry is not a promise that every browser, CDN or third-party cache copy disappears instantly.
- If the upload page shows an expiry time for your result, treat that value as the service timing for that upload.
How temporary retention is scheduled
The upload service records an expiry time for temporary images. Scheduled cleanup removes expired files; the exact time a public link stops working can vary.
- The retention clock starts when a temporary upload completes successfully and a hosted URL is created.
- API success payloads may include expires_at as an ISO-8601 UTC timestamp ending in Z (example style: 2026-08-05T12:00:00.000Z).
- expires_at is calculated from the upload completion time plus 1, 7 or 30 days for temporary durations. Permanent storage does not use this temporary expiry field.
- The public /upload page shows the retention you chose; it may not always display the raw expires_at field in the result panel.
- The original link may remain reachable after its recorded expiry until cleanup runs. Browser, CDN or third-party caches may retain copies longer.
- Scheduled cleanup removes expired objects after the recorded expiry; the timestamp is not a guarantee of immediate deletion.
- Ordinary temporary uploads are not the same as approved long-term (permanent) storage, which requires a separate approved storage code on /upload.
- To request removal of an image you control, send the full image URL via the contact page or [email protected].
Expiry vs removal request
The public upload page does not provide a self-serve instant delete control for normal temporary uploads. To request removal of an image you control, send the image URL through the contact page or email [email protected].
Waiting for expiry and sending a removal request are different actions. A removal request is handled by support; it is not the same as proving every cached copy is gone worldwide.
Which retention to choose
1 dayQuick previews and short support chats.
7 daysDraft feedback and short review cycles.
30 daysLonger temporary references that still should not be permanent.
FAQ
When does the countdown start?
After a successful upload creates the hosted URL for the retention you selected beforehand.
Does expiry clear all caches immediately?
No. The hosted file is intended to stop being available at the URL; third-party or browser caches may lag.
Can I delete a temporary image myself on the page?
There is no public instant-delete control for normal temporary uploads. Request removal with the image URL via contact.
What should I include in a removal request?
The full image URL and enough context to show you control or are reporting the content.
Is permanent storage the same as temporary expiry?
No. Permanent storage needs an approved long-term code and follows different rules on the upload page.