Set the deletion rule while uploading: a fixed expiry, the first successful image request, or a view limit. Add a password when access and retention both need boundaries.
Temporary hosting is useful only when the rule is predictable. These modes are not interchangeable.
Pick a duration and share normally during that window. Free supports one day, one week, and one month. Starter adds three months and no expiration. Pro and Business also allow a custom future date.
Best for project reviews, short-lived announcements, support screenshots, and handoffs with a known deadline.
The server atomically claims the image when the first successful direct image request arrives. A later request receives a not-found response. Loading the surrounding share-page shell by itself does not consume the image.
Best for a one-recipient visual that does not need to remain hosted. It does not stop the recipient from saving or photographing what they see.
Set a unique-view limit from 1 to 999. Repeated loads with the same browser fingerprint are ignored for 30 minutes. The image is deleted when the count is reached or after 30 days, whichever happens first.
Best for a controlled group where the number of expected viewers is clearer than the exact viewing time.
Use expiration when the file should stop being served after a condition. Use a password when only people who know a secret should reach the image before that condition. You can combine both controls.
Neither control can revoke a copy that a recipient has already downloaded. If the image is highly sensitive, minimize what the image reveals and use an encrypted end-to-end messaging service instead of a public web link.
Upload the draft and select one week, enough time for feedback.
Set a strong, unique password before starting the upload.
Send the share URL in one channel and the password in another.
Keep the source file locally. The hosted copy is removed after expiry.
The lifecycle is enforced by the application and storage layer, not by a note in the page copy.
The service validates the image, normalizes orientation, and strips embedded metadata.
The chosen expiration type, time, password state, and view limit are stored with the image record.
Every protected file request checks access and terminal conditions before image bytes are served.
Terminal records are removed from storage and no longer resolve as live image pages.
A successful direct request is the event that consumes it. Confirm the copied URL shape without fetching the file, or upload a separate test image.
Browser deduplication intentionally filters refreshes. A view limit is an access control for approximate unique viewers, not an advertising impression counter.
Expired, burned, and view-limited images are not recoverable through the sharing service. Retain the source file under your own backup policy.
A temporary image link points to an uploaded image with a deletion rule. The rule can be a fixed time, the first successful image request, or a selected number of unique views.
The image is claimed for deletion when the first successful direct image request reaches the server. The claim is atomic, so simultaneous requests cannot each receive a fresh copy. Opening only the share-page shell does not consume the image.
Choose a limit from 1 to 999. The service deduplicates repeated requests from the same browser fingerprint for 30 minutes, then removes the image when the limit is reached. View-limited uploads also expire after 30 days if the limit is not reached first.
Yes. Password protection can be combined with time-based expiration, delete after view, or a view limit. A viewer must unlock the image before the protected image bytes are served.
No. Temporary deletion rules are intended to remove the stored image. Keep the original file elsewhere and choose a longer expiration if the recipient might need more time.
Learn how retention, identity, and automation fit together across the service.
Upload a file, select its expiration rule, and add a password if the image needs an access boundary too.