Skip to main content
Deleting an asset is a two-step process.

​
Step 1: soft delete

Delete on an asset row moves it to the recycle bin.
  • The asset still serves at its URL. Nothing hosted or embedded breaks.
  • It shows up in the Recycle bin view (toggle at the top of the Assets tab).
  • It still counts against your storage budget.
The two-step exists because “an asset is not attached to a variant” is not the same as “the asset is not in use”. Emails you sent last month, third-party embeds, cached copies in a stakeholder’s browser all of those might still hit the URL. Soft-deleting without breaking the URL gives you a moment to notice.

​
Step 2: permanent delete

Permanent delete in the recycle bin actually removes the file.
  • The R2 object is deleted.
  • The Cloudflare cache is purged (within minutes).
  • The URL will 404 from now on. Anything referencing it stops working.
  • Storage is freed, your budget usage drops.
This step is confirmation-gated. There is no undo.

​
Restore

From the recycle bin, Restore brings a soft-deleted asset back to active, no permission changes, no URL changes, just moves out of the bin.

​
Storage stays used until permanent delete

The Assets tab meter includes soft-deleted files. This is the opposite of what you might expect, most trash bins in most products “free up space” on soft delete. Ours does not, because the URL still serves and R2 still stores the bytes. If you are running close to your plan’s storage budget, soft delete does not help. Permanent delete does.

​
Dependents check

Before deleting, click the asset to see which variants reference this file. Substring match on the URL across every variant’s JS and CSS on the site. Zero dependents is safe to delete. Non-zero dependents means at least one variant will break if you delete the file, decide whether to update the variant first.

​
Assets that were used a long time ago

The dependents check reads current variants. It does not know about:
  • Archived experiments, the variants are still in the archive; the URL might still be embedded in the archived variant’s JS/CSS.
  • Cloned experiments, if the clone kept a hard-coded URL to the original’s asset, the dependents check catches it via string match, which is why we do string match rather than a metadata-only lookup.
  • External embeds, an email you sent, a third-party site that hotlinks the URL. Nothing on our side can see those.
For assets that have been around a while, prefer soft delete over permanent delete. A week in the recycle bin gives you time to notice external breakage.