If you searched for a browser-console JavaScript trick to bulk delete Cloudflare DNS records, you are probably not chasing a hack for its own sake. You are cleaning up a live zone after a rushed migration, a bad import, or years of vendor drift. In that situation, speed matters, but control matters more.
The real objective is not to delete faster. It is to remove the right records without breaking email, domain verification, redirects, or production traffic. Old DevTools snippets depended on Cloudflare's front-end markup and button selectors. That was always brittle. Cloudflare now gives you first-party ways to do this safely, so the better path is simple: use the dashboard for one-off cleanup, and use the API when you need a repeatable runbook.
Start with Cloudflare's bulk delete for one-off cleanup
For a single zone and a manageable list of records, start in the DNS Records page. Cloudflare's current bulk workflow is available on all plans and lets you select records, choose Delete records, and type DELETE to confirm. Current limits are 200 records per action on Free and 3,500 per action on Pro, Business, and Enterprise.
That is a much better default than running JavaScript against a live dashboard. You can see exactly what is selected, another teammate can review it, and you are not betting a production change on CSS classes or a half-working click loop.
- Export the zone before you touch anything and attach that export to the ticket or change record.
- Review risky records separately:
MX,SPF,DKIM,DMARC, vendor verificationTXTrecords, and anything tied to redirects or SaaS cutovers. - Put one person in charge of the change window. DNS cleanup gets messy when several people click around at once.
Use the API when the job must be repeatable
If you manage several client zones, need a reviewable workflow, or want to delete records by rule instead of by eyeballing them, use the API. Cloudflare's delete endpoint requires DNS Write, and Cloudflare prefers API tokens over the older Global API Key. For agency teams and ops leads, that is the difference between a reusable runbook and a one-night workaround.
Cloudflare also notes that the free-text search parameter on the list endpoint is for human use, not automation. In practice, the safe pattern is to preview candidate records first, review the IDs and names, and only then run the delete. The example below keeps that review step explicit:
export ZONE_ID=your_zone_id
export CLOUDFLARE_API_TOKEN=your_token
curl --silent "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?per_page=50000" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
| jq -r '.result[]
| select(.type == "TXT" and (.name | endswith(".old.example.com")))
| [.id, .type, .name, .content]
| @tsv'If that preview looks right, delete only those matching record IDs:
curl --silent "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?per_page=50000" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
| jq -r '.result[]
| select(.type == "TXT" and (.name | endswith(".old.example.com")))
| .id' \
| while read -r id; do
curl --silent --request DELETE \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$id" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
echo
doneThis follows Cloudflare's own list-and-delete pattern, but scopes it to a subset you have reviewed. That is usually the difference between controlled cleanup and self-inflicted outage. If you are working on a very large zone, add pagination instead of assuming one response will cover every record.
If you need one reviewed change set, use the batch endpoint
When a change window includes several coordinated edits, Cloudflare's /dns_records/batch endpoint is usually cleaner than a long loop of individual requests. It can execute DELETES, PATCHES, PUTS, and POSTS in a single request, which makes peer review and change approval easier.
{
"deletes": [
{ "id": "RECORD_ID_1" },
{ "id": "RECORD_ID_2" }
]
}The operational nuance matters here: Cloudflare executes the batch as one database transaction, but propagation across the network is not atomic. Treat coordinated delete-and-replace work like a real release. Validate the final DNS state, then validate the services that depend on it.
Sometimes rebuilding the zone is smarter than deleting
If the zone is messy because of years of vendor experiments, migrations, and handoffs, hundreds of tiny deletes may not be the best fix. Cloudflare supports exporting and importing records, which is often the cleaner approach when you want a reviewed before-and-after file. Cloudflare's current docs also give you useful planning limits: the zone file size limit is 256 KiB, and the import API rate limit is three requests per minute per user.
For business owners and operations leads, this is often the more valuable decision: do not optimize for the fewest clicks; optimize for the clearest rollback path and the least ambiguity about what the final zone should contain.
A practical workflow for live client zones
- Export the current zone and keep that snapshot with the ticket.
- Identify candidate records by type, name pattern, content, or business purpose before deleting anything.
- Preview the exact records to remove and get a second review if the zone supports revenue, email, or customer logins.
- Use dashboard bulk delete for simple one-off cleanup, or the API and batch endpoint for repeatable, audited work.
- After the change, test the website, email flow, redirects, and any vendor verification that depends on DNS.
If you need help cleaning up a live Cloudflare zone without guessing which records still support email, SaaS verification, or production traffic, Greg can help turn the cleanup into a controlled operational change.
Need help with this kind of work?
Bring Greg in to plan and execute a safer DNS cleanup or migration. Get in touch with Greg.