Edge geolocation with request.cf on Cloudflare Workers

Every request that hits a Cloudflare Worker can expose rich network metadata on request.cf (IncomingRequestCfProperties): country, colo, ASN, timezone, TLS version, and more. For many personalization, compliance, and debugging features, that is enough - no third-party geo IP database required.

The Where Am I experiment returns those fields as JSON so you can explore what Cloudflare attaches in your colo and copy the pattern into products.

Cloudflare products in this patternCopy Anchor Link

What you get without a geo databaseCopy Anchor Link

Typical fields teams use (availability can depend on request path and account features - always check the live object):

Treat values as hints, not legal identity. VPNs, mobile carriers, and corporate egress will skew country. Document that in product UX and privacy policies.

The smallest useful APICopy Anchor Link

Where Am I is intentionally tiny:

GET / → JSON of selected request.cf fields (+ request basics)

Ideal for:

• Teaching how edge context works on Workers
• Debugging “why is this user in the wrong locale?”
• Smoke-testing deployments from different networks

curl -fsSL https://<your-worker>/ | jq .

Call it from home, a phone hotspot, and a cloud shell - watch colo and country change.

Product patterns on top of request.cfCopy Anchor Link

1. Locale bootstrap - default language/currency from country, allow override
2. Abuse signals - log ASN + path for review; pair with Rate Limiter Demo concepts or WAF rate limiting
3. Support tooling - show customers which colo served an error page
4. Radar enrichment - ask network questions via Radar One Question against Cloudflare Radar
5. Latency maps - compare POPs with Multi-POP Latency Map

Privacy and compliance notesCopy Anchor Link

• Prefer coarse fields (country, colo) over storing raw IPs when possible
• Declare what you log; set retention
• Do not treat country as GDPR “adequate” proof of residency alone
• Bot-related scores may be plan-gated - see Bots documentation

Local vs productionCopy Anchor Link

request.cf behavior can differ in local wrangler versus production. Always validate field presence on a deployed Worker before building hard dependencies. The Workers Request docs are the source of truth for property names.

Deploy Where Am ICopy Anchor Link

1. Skim IncomingRequestCfProperties
2. Open Where Am I
3. One-click Deploy or run with Wrangler
4. Hit the root endpoint from two networks
5. Copy only the fields your product needs

You learn request.cf with a live API instead of reading property tables alone - then keep Workers as the vehicle and Cloudflare’s edge metadata as the product capability you are actually shipping.

Production checklistCopy Anchor Link

1. List which request.cf fields you actually need - drop the rest.
2. Validate field presence in production (local wrangler can differ).
3. Document VPN/carrier caveats in UX copy.
4. Keep PII out of analytics; prefer country/colo/ASN aggregates.
5. Combine with Radar only when enrichment is worth the extra call.

FAQCopy Anchor Link

Is country GDPR-grade location proof?Copy Anchor Link

No. Treat it as a hint for defaults, not legal residency evidence.

Why is colo null sometimes?Copy Anchor Link

Not every execution path exposes every property. Guard with optional chaining and defaults. See IncomingRequestCfProperties.