What Is beacon.min.js? Cloudflare's Auto-Injected Analytics, and How to Turn It Off (2026)
Short answer: beacon.min.js is Cloudflare's Real User Measurement script. If your domain is on a free Cloudflare plan and proxied through them (the orange cloud), Cloudflare has been injecting it into your HTML by default since September 2025 — you did not add it, it is not in your repo, and it arrives before your page reaches the browser. Paid plans are opt-in only. You turn it off in Analytics & Logs → Web Analytics → Manage Site → Advanced Options → JS Snippet injection.
Two things are worth separating here, because the thread that put this on the front page of Hacker News this week mixed them together:
- The GDPR panic is mostly overstated. The default configuration excludes EU visitor data. Cloudflare's own words, from the thread: "we will not collect any RUM metrics from traffic that passes through our European and UK data centers."
- The consent problem is real anyway, and it is a different problem. The beacon is injected at the edge, so it lands on the page before your consent management platform gets to run. There is nothing for your CMP to gate. That is true regardless of who the visitor is.
I run a hosting company, so treat me accordingly — I have an obvious interest in you thinking hard about what your platform does to your bytes. That is exactly why I want to be careful with the facts rather than loud about them.
What actually happens
Someone moved their nameservers to Cloudflare and later found a 31KB JavaScript file executing on a site they had deliberately built with no JavaScript at all — which sounds like a compromise until you read the docs and realise it is just what the free plan does.
The mechanism matters more than the outrage:
- Injection happens at the edge, in Cloudflare's proxy, on the way to the visitor. Your origin server sends HTML without the script; the visitor receives HTML with it.
- It only applies to proxied records — orange cloud. DNS-only records pass through untouched.
- With automatic setup and no Rules configured, it goes on every page of every subdomain in the zone, not just the pages you were thinking about.
- When auto-injected on a proxied domain, the beacon reports to
/cdn-cgi/rumon your own domain, so it does not show up as a third-party request in the obvious place you would look for one.
That last detail is the one I would have missed. A quick scan of third-party domains in your network tab does not catch it.
Is Cloudflare's beacon a GDPR problem?
Probably not in the default configuration, and I would rather say that plainly than farm the fear.
Here is what Cloudflare stated in the discussion, verbatim: "The version of Web Analytics that will be enabled by default excludes data from EU visitors (this can be changed in the dashboard if you want)." And: "you can choose to drop requests from European and UK visitors if you so desire... we will not collect any RUM metrics from traffic that passes through our European and UK data centers."
So if you are an EU business serving mostly EU visitors, the default posture is that the measurement is not collected for them. That is a genuinely more thoughtful default than "collect everything and let the customer sort it out."
What that statement does not settle — and what I could not confirm from Cloudflare's public documentation either way — is whether the script is still served and executed in EU visitors' browsers while the metrics are discarded on Cloudflare's side. "We do not collect" and "we do not inject" are different promises, and only one of them was made. If that distinction matters for your compliance posture, check it on your own domain rather than taking my word or theirs. The command is in the next section.
The consent point stands separately from all of this. Edge injection cannot be gated by a consent banner that has not loaded yet, so any tag-governance story you tell your auditors has a hole in it while automatic injection is on.
How to check what your host injects
This is the part worth keeping regardless of which platform you are on. Ask your origin for the page, then ask the public internet for the same page, and compare.
# 1. What your server actually sends (replace with your origin IP)
curl -s --resolve example.com:443:203.0.113.10 https://example.com/ > origin.html
# 2. What a visitor actually receives
curl -s https://example.com/ > edge.html
# 3. Anything your origin never wrote
diff origin.html edge.html
For the specific case, a direct grep is enough:
curl -s https://example.com/ | grep -oE 'cloudflareinsights|beacon\.min\.js|/cdn-cgi/rum'
Empty output means nothing is being injected on that path. Any hit means something is editing your HTML between your server and your users.
Worth running against a few different paths, not just /. Rules can scope injection to a subset of pages, so the homepage being clean does not prove much on its own.
Turning it off
In the Cloudflare dashboard:
- Analytics & Logs → Web Analytics
- Manage Site on the domain
- Expand Advanced Options
- Toggle off JS Snippet injection
If you actually want the performance data — and RUM data is genuinely useful, that part of Cloudflare's argument is fine — disable the automatic injection and add the snippet yourself. Then it is a tag like any other tag: your CMP can gate it, your CSP applies to it, and it is visible in your repository where the next person can find it.
One quirk to know before you go looking: several people reported having to enable Web Analytics first in order to reach the switch that turns the injection off.
What Cloudflare collects, and for how long
| Thing | Detail |
|---|---|
| Script | beacon.min.js, roughly 31KB, from static.cloudflareinsights.com |
| Reporting endpoint | /cdn-cgi/rum on your own domain when auto-injected |
| Default on | Free plans, since September 2025 |
| Default on paid plans | No — opt-in only |
| EU/UK visitors | Excluded from collection in the default configuration |
| Raw data retention | Unsampled for 7 days, then aggregated down to roughly 10% |
| Scope with automatic setup | Every page and subdomain in the zone, unless Rules narrow it |
The part I actually care about
The reason this landed on the front page is not that RUM is sinister. It is that the boundary moved without anyone noticing, and a free plan turned out to include a term nobody read.
It rhymes with the other platform stories I keep writing about here — Netlify moving to credit pricing, or metered bills that drift upward month after month — in the sense that the platform changes something in the middle of your stack, the change turns out to be perfectly defensible once you go and read the docs, and you find out about it later than you would have liked. The free tier is usually where it lands first, because that is where the leverage is and where nobody is reading a contract.
I do not think Cloudflare did anything villainous here. Their EU default is more careful than most, and their engineer showed up in the thread and answered directly, which is more than most companies manage. But "on by default for the people who are not paying, opt-in for the people who are" is a choice, and it is worth seeing it clearly rather than being annoyed at it vaguely.
Since it would be cowardly to write this without stating our own position: Hostim does not modify customer response bodies. The ingress in front of your app sets one annotation, x-forwarded-proto: https, which is a request header going towards your container — no sub_filter, no snippet injection, nothing added to what you send back. You do not have to take my word for it, and you should not: run the same diff from the section above against your own Hostim app. If it ever comes back non-empty, that is a bug and I want to hear about it.
FAQ
What is beacon.min.js?
It is Cloudflare's Real User Measurement (RUM) script, about 31KB, served from static.cloudflareinsights.com. It measures page performance in real visitors' browsers and reports back to Cloudflare.
Why is beacon.min.js on my site when I never added it? Because Cloudflare injects it at the edge. Free plans have this on by default since September 2025 for domains proxied through Cloudflare (orange cloud). It never touches your source code, so it will not appear in your repository.
How do I disable Cloudflare's automatic beacon injection? Cloudflare dashboard → Analytics & Logs → Web Analytics → Manage Site → Advanced Options → toggle off JS Snippet injection. You may need to enable Web Analytics first before the toggle is reachable.
Does the Cloudflare beacon violate GDPR? In the default configuration Cloudflare states it does not collect RUM metrics from traffic through its European and UK data centres, so the collection concern is largely addressed. The separate, unresolved issue is consent management: because the script is injected at the edge, it loads before your consent platform can gate it.
Is Cloudflare Web Analytics injected on paid plans too? No. Cloudflare states all paid plans are opt-in only. The default-on behaviour applies to free plans.
How do I see what my hosting provider injects into my pages? Fetch the page from your origin and from the public URL, then diff the two. Anything present in the second and absent in the first was added in transit. There is a copy-paste version of this above.
If you would rather your hosting provider just serve what you gave it, that is roughly the whole design philosophy behind Hostim — your container, your bytes, a flat monthly price, hosted in the EU. New projects get a free 5-day trial, no card.
👉 Deploy an app on Hostim, free 5-day trial, no card
We're building Hostim.dev to make this simpler, and we are happy to answer any questions.
Last updated: 17 August 2026. Cloudflare's quoted statements are from its engineer's replies in the Hacker News discussion on 16 August 2026; the beacon endpoint, sampling and retention details are from Cloudflare's Web Analytics documentation, checked 17 August 2026. Defaults change — verify against your own dashboard before relying on any of this.