Purge everything vs. selective purge
Purge everything clears a zone's entire cache in one call and is the right choice after a deploy that changes many files. Selective purge clears only the URLs, hostnames, tags or prefixes you name, keeps the rest of the cache warm, and is the right choice for a single changed asset.
Last updated:
Cloudflare offers five ways to invalidate cached content. Since 3 April 2025 all five are available on every plan, including Free — before that date, three of them were Enterprise-only, which is why a lot of older articles still say otherwise.
The five methods compared
| Method | What it clears | Best for | Plans |
|---|---|---|---|
| Purge everything | The entire cache of one zone | A deploy that touched many files, or when you are not sure what changed | All |
| Purge by URL | The exact URLs you list | One asset you just replaced | All |
| Purge by hostname | Everything served from a hostname | A subdomain you rebuilt, e.g. img.example.com | All |
| Purge by prefix | Everything under a URL path | A whole section, e.g. example.com/blog/ | All |
| Purge by tag | Everything tagged with a Cache-Tag header | Content grouped logically across paths | All |
When to purge everything
Purging everything is one API call, needs no list of files and cannot miss anything. That is its whole appeal, and it is a real one: after a static site rebuild where every hashed filename changed, enumerating the changes is pointless work.
The cost is that your cache hit ratio drops to zero for that zone. Every visitor after the purge hits your origin until the cache refills. On a small site that is a blip. On a site doing serious traffic, it is a spike of origin load that you chose to create — and if your origin is a single modest server, that spike is the thing that takes it down.
When to purge selectively
Selective purge keeps the rest of the cache warm. You changed one stylesheet; there is no reason for every product image on the site to be re-fetched from origin.
The trade-off is precision. A purge by URL matches exactly the URL you give it, including the query string and the protocol. These are three different cache entries:
https://example.com/style.csshttps://example.com/style.css?v=2https://www.example.com/style.css
Purging the first does nothing for the other two. This is the single most common reason people conclude that "purge doesn't work": it worked, on a URL nobody requests.
Hostname, prefix and tag
Between "one exact URL" and "the entire zone" there are three middle options, and they are underused because for years they cost Enterprise money:
- Hostname is the bluntest of the three and needs no preparation. Rebuilt everything under
cdn.example.com? One call. - Prefix works on URL paths, so
example.com/blog/clears every post without touching the shop. - Tag is the most powerful and the only one that needs setup: your origin has to emit a
Cache-Tagresponse header. Once it does, you can purge "everything about product 4471" regardless of how many URLs that spans.
A decision that takes five seconds
- Do you know exactly which files changed, and are there fewer than a hundred? Purge by URL.
- Did a whole subdomain or section change? Purge by hostname or prefix.
- Does your origin already emit
Cache-Tag? Purge by tag. - Otherwise, or if you are unsure and the site is small? Purge everything.
How FlarePurge handles it
FlarePurge covers total purge and selective purge by URL and hostname, which together account for the overwhelming majority of real purges. Paste your URLs and the app splits them into batches automatically, so a list of 90 URLs becomes three API calls without you thinking about it.
It also does bulk purges: every favourite zone at once, or every zone of an entire account behind one confirmation — with the concurrency capped so you do not trip Cloudflare's rate limits. Those limits are documented here.