Self-Destructing Links That Disappear After Use

Three switches, and they stack

Most "self-destructing link" tools give you one behaviour: burn after reading. zip1.io gives you three independent controls on the same short link, and you can set any combination of them when you create it.

Set two and the stricter one wins: a link capped at 5 clicks and a Friday expiry dies on the fifth click or on Friday, whichever comes first. At redirect time the password is checked first, then the click cap, then the expiry.

If you only want the single-use case, the dedicated walkthrough is on one-time links. This page is about the other two axes and how they combine.

An expiring link stops redirecting at a time you set, or after a click limit

Paste your URL on the home page, click Advanced Options, and fill in Expires at. It is an ordinary date-and-time picker showing your local timezone; the page converts it to UTC before submitting, so a 6pm expiry means 6pm where you are.

Two fields sit right next to it — Max clicks and Password — and nothing stops you filling in all three. Then click Shorten.

The expiry has to be at least five minutes ahead. A timestamp in the past, or one four minutes out, is rejected rather than silently accepted as an already-dead link.

…or from the API, in one request

No key, no account, 10 link creations per minute per IP:

curl -X POST https://zip1.io/api/create \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/q4-board-pack.pdf",
    "alias": "board-q4",
    "expiration-time": "2027-01-31T18:00:00Z",
    "max-clicks": 12,
    "password": "Preview@2026"
  }'

# Response:
# {"short_url": "https://zip1.io/board-q4", ...}

expiration-time must be ISO 8601 with a timezone — 2027-01-31T18:00:00Z or 2027-01-31T19:00:00+01:00. A naive timestamp with no offset is rejected, because "6pm" without a timezone is not a moment. Passwords need at least 8 characters including a letter, a digit and one @ or ., and no two of those special characters in a row.

Full parameter list and error codes are in the API docs.

What "disappears" actually means

This is where most pages on this topic get vague, so plainly:

• The redirect stops. Once the cap or the expiry is passed, the short URL serves an expired-link page instead of sending anyone onward. That is the whole mechanism, and it is enforced on our side on every request — there is no client-side timer to bypass.
• The record is not deleted. The link stays in our database and its stats page keeps working, so you can still see how many people made it through before the door closed, and from where.
• The destination is untouched. zip1.io never had control over the page or file at the far end. Expiring the short link closes one route to it; the original URL still works for anyone who has it. If the destination itself must go away, revoke it at the source too.
• It cannot be undone or extended. Links are immutable after creation. That cuts both ways: you cannot rescue a link that expired early, and nobody can quietly re-point a link you already handed out.

One practical wrinkle on click caps: preview crawlers count. Paste a capped link into Slack, Discord or iMessage and the platform may fetch it once to render a card, spending a click before your recipient sees it. That fetch does not use a click when the link has a password, because it stops at the password page, or when block-bots is set, because known bots are turned away before the click is recorded. The one-time links page has the workarounds. Known bots are listed by name on the stats page, and those clicks stay in the totals.

Private link sharing: what this is, and what it isn't

Short-lived and unguessable is genuinely useful. It is not the same as private, and it is worth knowing exactly where the line falls.

Without a password, the stats page is public. Anyone who has the short link can open its stats page and read the destination URL, along with the click totals by country, browser, OS and referrer, and the time of the last click — including after the link has expired. Anyone with the short link can see its stats. Visitor IP addresses are stored to count unique visitors. They are never shown on the stats page or included in the export. If the destination URL is itself the secret (a signed download link, a pre-filled form, an internal dashboard), set a password. The same password then gates the redirect and the stats page, and the destination stops being readable to anyone without it.

We can read the destination. zip1.io stores it in plaintext, because a redirect service has to know where it is redirecting you. Passwords are stored only as a one-way fingerprint, never as readable text, so the passphrase itself is not recoverable from our database, but the URL is. For material where a third party must not be able to read it at all, use an end-to-end encrypted tool — OneTimeSecret, Privatebin, or an encrypted file transfer — and consider shortening that link if you need it to fit on a slide.

A password is a gate, not encryption. It stops a casual opener, a forwarded link, and a crawler. It does not protect against someone who already has both the link and the password, and it does not stop the recipient from copying the destination once they are through. More on the mechanics and the honest limits on password protected links.

Need exactly one open and no clock? Use a one-time (click-limited) link. Add a password gate.

Four things people actually do with this

How the shorteners compare on expiry

Comparison reflects publicly documented free-tier features at time of writing. Dedicated secret-sharing tools like OneTimeSecret and Privatebin are a different category — they host the secret and encrypt it, rather than redirecting to a URL you control. Use those when the message itself is the secret; use this when the destination is a page or file of your own.

FAQ

• What is a self-destructing link?

  A short URL that stops working on its own, without you going back to revoke it. On zip1.io a link can self-destruct in two ways: a click cap limits the number of redirects, and an expiry date sets a moment after which the link is dead. Set both and whichever comes first ends the link. A visitor who arrives afterwards gets an expired-link page instead of the destination.

• How do I set an expiry date on a link?

  On zip1.io, open Advanced Options under the URL box and fill in the "Expires at" field. It is a normal date-and-time picker in your local timezone; the browser converts it to UTC before sending. Via the API, pass expiration-time as an ISO 8601 timestamp that includes a timezone, for example 2027-12-31T23:59:00Z. The expiry must be at least five minutes in the future or the request is rejected.

• Does the destination URL get deleted when the link expires?

  No, and this is the part worth being precise about. "Self-destructing" means the redirect stops: the short link returns an expired-link page instead of sending anyone onward. The record stays in our database, the click analytics stay readable, and the file or page at the far end is completely untouched — zip1.io never had control over it. If the destination itself must become unreachable, revoke it at the source as well.

• Is a self-destructing link private?

  It is unguessable and short-lived, which is not the same as private. Anyone who has the short link can open its stats page, when the link has no password, and read its destination URL. zip1.io stores that destination in plaintext because it has to in order to redirect. The page shows click totals by country, browser, OS and referrer, and the time of the last click. Anyone with the short link can see its stats. Visitor IP addresses are stored to count unique visitors. They are never shown on the stats page or included in the export. Adding a password closes both doors at once: the redirect and the stats page then both require it. For secrets that must never touch a third-party server, use an end-to-end encrypted tool instead.

• How is this different from Privnote or other self-destructing notes?

  Those tools share a message that burns after reading. Zip1 shortens a URL you already control and stops redirecting after expiry (and/or after N clicks). Analytics for the short link remain available after expiry / first click; the file or page at the far end is untouched unless you revoke it at the source.

• Can I combine an expiry date, a click cap and a password?

  Yes. All three are independent options on the same link and they stack. The password is checked first, then the click cap, then the expiry. A common shape is a click cap of 1 plus a 24-hour expiry: one use, and if nobody uses it, it dies anyway.

• Can I extend or change a link after it has expired?

  No. zip1.io links are immutable once created — the destination, the click cap, the expiry and the password are all fixed at creation. If a link expired sooner than you meant, create a new one and re-share it. That immutability is deliberate: it means a link you handed out cannot be quietly re-pointed at somewhere else later.

• Is it free?

  Yes. No signup, no monthly link cap (500 a day on the site, 1,000 by API), and no paid tier gating expiry or passwords.

Related