Geofence Map Tool
Plan a geofence visually, then export as KML or extract the coordinates for Radar, Google Geofencing API, Braze, or any geofencing platform.
Plan a Geofence in Under 60 Seconds
Geofence planning doesn't need to happen inside your app's SDK. Design the boundary here first — where it sits, how large it should be, what it should cover — then export the coordinates to your production geofencing platform. This separates the planning step from the implementation step, which is usually how product and engineering teams collaborate.
- 1Search for the center point. Type the address, postal code, or landmark at the center of your geofence. Address search works globally — city, street, or coordinates all work.
- 2Set your radius in kilometers. Common sizes: 500 m for a single store, 2 km for a neighborhood campaign, 10 km for a metro-level trigger, 50 km for a regional event.
- 3Position and resize. Drag the center pin to fine-tune placement. Adjust the radius field or drag the circle edge. The boundary updates in real time.
- 4Export. Click Export KML to download a file ready for Radar.io, Google Earth, QGIS, or any tool that accepts KML. Use Export PNG for design mocks or documentation.
The exported KML uses standard WGS84 coordinates, which is what all major geofencing platforms expect. No coordinate conversion needed.
What Is a Geofence?
A geofence is a virtual boundary around a real-world location. When a mobile device (or any GPS-equipped asset) enters, exits, or dwells inside the boundary, software triggers an event — a push notification, a database update, a workflow step, an analytics log.
Circle geofences are the most common type. They're defined by a center point (latitude and longitude) and a radius measured in meters or kilometers. Polygon geofences — which trace an arbitrary shape — are supported by most major platforms but require more work to author.
Geofences are enforced in two ways. On-device geofences live inside a mobile SDK and trigger events locally when the device crosses the boundary. Server-side geofences query the user's reported location against a stored boundary on your backend. The first is more efficient for battery; the second is more flexible for complex logic.
Geofencing is widely used in retail proximity marketing, fleet management, workforce clock-in automation, asset tracking, and compliance zones.
How Geofencing Works Under the Hood
Three things happen when a geofence triggers an event: the device determines its location, the system compares that location to the boundary, and software executes a response.
Location sources. Most geofences rely on GPS when outdoors. Indoors or in dense urban areas (where GPS signal reflects off buildings), systems fall back to Wi-Fi positioning, cellular triangulation, or Bluetooth beacons for sub-meter accuracy. Accuracy ranges from under 5 meters in ideal GPS conditions to 50+ meters in urban canyons.
Trigger types. Platforms distinguish three event types:
- Entry: fires when the device crosses the boundary into the geofence.
- Exit: fires when it crosses the boundary going out.
- Dwell: fires when the device has stayed inside the boundary for a specified time (usually 1–30 minutes).
Dwell events are the quiet workhorse of geofencing. Retail attribution, workforce clock-in, and anti-fraud systems all depend on dwell rather than raw entry, because a drive-by crossing at 80 km/h is noise, not signal.
Battery impact. Circle geofences on iOS and Android run at the OS level, which means they're battery-efficient — the radio doesn't have to poll GPS constantly. Polygon geofences, custom triggers, and high-frequency proximity queries run at the application level and drain the battery faster.
Platform limits. iOS caps apps at 20 active geofences per app. Android allows 100 per app. Most production systems get around this with dynamic geofence loading — swapping active fences based on current location — but this adds complexity.
Geofence Types: Circle vs Polygon
Most geofences are circles. They're simple to author (one point, one distance), efficient to evaluate (is this GPS coordinate inside this radius?), and supported natively by every major SDK. They work well when the triggering zone is symmetric — a store location, a stadium, a workplace.
Polygon geofences trace an arbitrary shape. They're the right choice when the boundary follows a real-world feature: a city-center district, a shopping mall's actual footprint, a warehouse perimeter, a park. Polygons take more work to author (you draw each vertex) and cost more CPU to evaluate, but they eliminate the dead zones and false positives that circles produce in irregular spaces.
Our tool produces circle geofences. For polygon planning, you'll want a dedicated GIS editor like QGIS or a purpose-built tool like geojson.io. We export KML, which both tools accept.
Practical rule: start with a circle. 80% of geofencing use cases are well-served by a well-placed circle. Upgrade to polygon only when the circle produces obvious false triggers at the boundary or misses obvious real-world zones.
Geofencing Platforms Comparison
If you've planned your geofence here, your next step is implementing it in a production platform. Below is how the major geofencing platforms compare on the dimensions that matter for most teams.
| Platform | Type | Geofence Limit | Polygon Support | Best For |
|---|---|---|---|---|
| Radar.io | Standalone SaaS | Unlimited (paid plans) | Yes | Product teams wanting a managed geofencing layer without SDK overhead |
| Google Geofencing API | Mobile SDK (Android) | 100 per app | Circle only (native); polygon via server | Android-only apps, cost-sensitive teams (free with Google Play Services) |
| Apple Core Location | Mobile SDK (iOS) | 20 per app | Circle only | iOS-native apps; hard limit forces dynamic geofence management |
| PlotProjects | Marketing platform | Plan-based | Yes | Marketing teams running proximity campaigns at scale |
| Braze | Customer engagement | Plan-based | Yes | Consumer brands with existing Braze messaging infrastructure |
| OneSignal | Push notifications | Paid tier | Limited | SMB teams wanting geofenced push without a dedicated location stack |
Limits and features change frequently — verify each platform's current docs before committing. This comparison reflects publicly documented capabilities as of early 2026.
Common Geofence Sizes and Use Cases
| Radius | Area Covered | Typical Use | Business Scenarios |
|---|---|---|---|
| 100 m | 0.03 km² | Single storefront or venue | In-store proximity offers, loyalty check-ins, foot-traffic counting |
| 500 m | 0.78 km² | City block or shopping center | Mall-level retargeting, event venue entry triggers |
| 1 km | 3.14 km² | Small neighborhood | Competitor conquesting (e.g. targeting shoppers near a rival store), hyper-local delivery zones |
| 2 km | 12.6 km² | Urban district | Walkable commute zone campaigns, university campus coverage |
| 5 km | 78.5 km² | Small city or metro core | Ride-share driver deployment zones, local news alerts |
| 10 km | 314 km² | Urban metro area | Fleet dispatch zones, regional retail attribution |
| 25 km | 1,963 km² | Metropolitan region | Sales territory boundaries, weather alerts |
| 50 km | 7,854 km² | State-level coverage | Regional distribution, franchise territory enforcement |
Accuracy, Privacy, and Platform Limitations
Honest caveats for anyone implementing geofencing in production:
Accuracy isn't uniform. Outdoor GPS typically gets you within 5–10 meters. Urban canyons and dense cities can drift to 20–50 meters. Indoor accuracy without Wi-Fi positioning is unreliable — often 50 meters or worse. Plan your geofence boundary with the worst-case drift in mind, or you'll get false triggers at the edges.
Small geofences are noisy. Radii under 100 meters frequently produce false positives (users triggered who weren't actually in the zone) and false negatives (users missed who were). For critical use cases — compliance, payments, clock-in — use 200 meters minimum and supplement with secondary signals.
Privacy regulations apply. In the EU, geofencing that stores or transmits user location data falls under GDPR. In California, CCPA applies. In both jurisdictions, you need explicit consent, a data retention policy, and a way for users to opt out. Platform SDKs handle the mechanics, but the policy and consent UI are your responsibility.
Platform limits bite at scale. iOS allows 20 geofences per app — hard limit. Android allows 100. Production apps that need more use dynamic geofence loading: activate the 20 closest to the user, swap them as the user moves. This is non-trivial to implement.