Transparency report

EVE Online players are a careful audience, and rightly so. When a map tool invites you to plan your travel on it, the obvious question is who gets to see that plan. This page is the complete answer: what runs in your browser, where every piece of data on the map comes from, what the optional EVE Online login can and cannot do, and exactly what is measured. The short version is that EO-Map is served as static files, the work happens in your browser, and the one small service the map reports usage to only accepts anonymous aggregate counters, so nothing on my side receives your routes or searches in any form. Every claim here can be checked from your own browser, and the section near the end shows how.

Everything you do runs in your browser

When the map loads, your browser downloads a 1.1 MB universe database built from CCP's official Static Data Export, build 3464040, and caches it for next time. Every interactive feature then works against that local copy. Route planning, the jump planner, jump range, force projection and avoid lists are all calculated by a routing engine running in a web worker inside the page. When you press calculate, the calculation itself makes no network request, so your start system, destination and route exist only on your machine. The usage counters described further down can count that a route was calculated, never what it was. The same is true of System Finder searches, star coloring, region compare, the 2D layout and the universe scale comparison: they are queries and rendering against data already sitting in your browser.

Your settings behave the same way. Panel layout, display options, visited systems, filters and any Ansiblex network you author in Force Projection live in this browser's own storage and are never uploaded. Clearing this site's data in your browser resets EO-Map to a first visit, because there is no copy of any of it anywhere else. A second, larger static-detail database of about 21 MB is background-loaded after the universe map renders and cached in the browser. Solar System View and Skyhook planet labels reuse it. Intel, described below, is the one panel that keeps a durable personal store: the reports you choose to save live in this browser's IndexedDB under the name eo-intel, the raw pasted text is never stored, and the panel's Settings tab exports, imports or deletes all of it.

Where the data comes from

Everything the map shows is public information, from three kinds of source.

• Static universe data comes from CCP's official Static Data Export, pinned at build 3464040 and shipped as the two databases described above.
• Dynamic overlays, meaning sovereignty, activity, incursions, faction warfare, industry cost indices, raidable Skyhooks and similar, come from CCP's public ESI API. A single small collector service fetches each public feed on the cadence CCP publishes it at and writes compact snapshot files to a static host. Your browser downloads the same files as every other visitor. There are no query parameters and no per-user requests, so nothing about what you look at inside an overlay is sent anywhere. This design is deliberate: one controlled fetch upstream instead of every browser hitting ESI separately.
• Market Supply starts from public market orders. EO collects them once a day, keeps a historical gzip archive that browsers never fetch, and derives a compact read model: a pointer, a daily catalog, and one object per item type. Your browser loads the catalog, then the selected item. The snapshot is listed sell orders, not completed trades, and it is the public NPC-station book; structure-market sells are incomplete. The panel shows the snapshot timestamp, and a last-known-good copy is served if a day's collection is delayed.
• Market History is the one panel where your browser does ask an upstream service directly: when you use it, the page requests EVE Online's official public trade history from CCP's ESI, one request per region for the item you picked. That is public, region-grain daily data, the same rows for every visitor; the request carries no login and no token, and what you chart is not reported to EO-Map. The panel's listed-supply charts reuse the daily Market Supply snapshot files described above.
• Regional Economy starts from CCP's official Monthly Economic Report. EO pins the published archive and serves a compact derived read of regional totals. Your browser loads a pointer, then the published series. It never downloads the zip. These are delayed monthly region totals, not live intelligence and not alliance output.
• Live kills are reported by zKillboard. The collector reads zKillboard's published feed and a relay pushes each kill to every connected map over a WebSocket. That connection is one way, server to you; your browser sends nothing back on it. The 72-hour kill history lives in your own browser's storage, not on a server, and clicking a kill opens the full killmail on zKillboard in a new tab. The connected maps figure shown in the app is a count of open connections, not of people.
• Intel, a controlled public beta, is the one panel with a durable personal store and the one with its own EO-Map service, used only when you ask. Your browser sends pasted names to CCP's public ESI directly to resolve characters, corporations and alliances, the same kind of public call Market History makes. It sends a character id, and nothing else, to EO-Map's killboard Worker, which collected that character's public record from zKillboard on the server side, so your browser never contacts zKillboard and sends no login. Nothing from Intel reaches an analytics event. The Intel page has the full description.
• Community observations for Metaliminal Storms and public Thera and Turnur connections come from EvE-Scout / Signal Cartel. Those too arrive as the same cached snapshot for every visitor. Volunteer scout names are not published.

Everyone gets the same snapshot files. ESI and zKillboard overlays are shown as published. EvE-Scout overlays drop volunteer names and are otherwise the same for every visitor.

The optional EVE Online login

EO-Map has no account of its own and nothing is held back behind a sign-in. You may optionally connect an EVE Online character. The default capability is Set Destination, which writes a planned route into your running EVE client as autopilot waypoints. The ordinary login asks for that one ESI scope, esi-ui.write_waypoint.v1. Personal route checks can also ask for NPC standings, esi-characters.read_standings.v1, and the Diplomacy skill level, esi-skills.read_skills.v1, only if you turn that navy check on. EO keeps only that Diplomacy level from the skill sheet. Security status and militia affiliation are public character facts and do not need a scope. My Geography asks for two more, each only when you choose that section: clone locations, esi-clones.read_clones.v1, and your item list, esi-assets.read_assets.v1. The location readout asks for the last system ESI reported, esi-location.read_location.v1, only when you press My Location. Every one of those is a separate consent on CCP's own pages, so the first login never carries them in quietly, and refusing one leaves the rest of the map working. What is never asked for at all is your contacts, your mail or anything to do with your money, and seven scopes registered on the application are never requested by any feature, including the ones for player structures and character contracts. The login runs on CCP's official SSO pages, so EO-Map never sees your account name or password.

My Geography is the one feature that reads something as personal as where your clones and items sit, so it is worth being exact about where that goes: nowhere. There is no EO-Map server behind it. Your browser asks CCP for the rows, and the rows, the systems they resolve to and the estimated values derived from them exist only in the memory of that page. They are never written to local storage, session storage or IndexedDB, never put in a share link, never attached to an analytics event, and never sent to EO-Map, because the one service on my side accepts nothing but pre-approved event names, category values from its own fixed lists and bucketed numbers, so clone and item rows have nowhere to go. Reloading the page or closing the tab loses them and you press Load again. Logging out, clearing the panel, switching character or a dead login clears them too. The login token itself is the exception that persists in this browser, and it is not the same thing as the data.

The token CCP returns is held in this browser's local storage and is sent only to CCP's own hosts, login.eveonline.com and esi.evetech.net. There is one narrow exception, and it applies to my own login alone: when I open the site's private usage dashboard as the owner, my browser sends my own short-lived token to the EO-Map analytics service once per request so it can check the request really comes from me. That token is never stored or logged there, refresh tokens never leave the browser, and no visitor's token is ever sent to EO-Map infrastructure. When you click Set Destination, your browser sends the waypoints directly to CCP's ESI with your own token, and the Smart waypoint mode asks EVE's public route service what your client would fly. Both requests go from your browser to CCP, so even at that moment I do not learn what route you planned. Logging out asks CCP to revoke the token and deletes it from this browser either way, and you can revoke access yourself at any time at developers.eveonline.com/authorized-apps.

What is measured, and what I can see

Site traffic is measured with Google Analytics on the map application and Cloudflare Web Analytics across the whole site. Both report aggregates: page views, sessions, referrers, country and browser type. Google Analytics uses its standard first-party cookies to tell a returning browser from a new one; advertising storage and Google Signals are switched off. Cloudflare's measurement is cookieless. Loading the map as an iframe embed on another site is still a page of eo-map.com, so Google Analytics records that the same way unless you have objected; the embedding site is not identified as a first-class dimension. The native JavaScript embed loads EO-Map's map code inside the host page and does not inject Google Analytics or EO-Map's own usage counters into that page. Neither identifies you, neither follows you to other sites, and there is no per-visitor profile behind either. Google Analytics and EO-Map's own usage counters are on by default. You can turn both off in Display Settings under Interface, Usage statistics, or on the privacy page; Cloudflare's cookieless measurement is separate and is not controlled there.

This page used to say there was no custom events endpoint, and that has changed, so I want to be exact about what the new one is. The map now keeps its own usage counters: it batches up small anonymous events and posts them to an EO-Map service. Each event is a name from a fixed list plus, for some events, a small allow-listed category such as which tool or map layer, a simple on-or-off flag, or numbers that were already rounded into coarse buckets before they left your browser. What gets counted is which tools get opened, which map layers get switched on or off, roughly how long a tool stays open, how many steps of a workflow ran, bucketed device, display and browser-engine classes, bucketed load and performance timings, and error counts. The service adds those to daily totals and keeps nothing else from the request. There is no cookie, no visitor or session identifier, and nothing that is stored includes your IP address. It cannot store text from your browser at all: the ingest only accepts event names it already knows, category values from its own fixed lists and pre-bucketed numbers, so a route, a search, a system id or a character name has nowhere to go even in a bug. Turning on Offline Mode in the app skips loading the Google Analytics script and stops these usage events too. Beyond those three channels there is no other measurement: no advertising, no third-party pixels.

So what I can actually see is visitor counts, country breakdowns, which tools are popular and roughly how they get used, all in total. What I cannot see, by construction rather than by promise, is anything about you individually: not the systems you look at, not the routes you plan, not your searches, not your character. That information never leaves your browser, so there is no log of it for me to read.

Check it yourself

None of this needs to be taken on trust. Press F12 to open your browser's developer tools and watch the Network tab while you use the map. On load you will see the site's own files, the databases, snapshot JSON from the overlay host, and the two analytics scripts. On the live site you will also see an occasional small POST to the analytics host: open one and you will find an event name and, at most, a short category word from a fixed list, an on-or-off flag or a handful of already-bucketed numbers, nothing else, because that is all the service accepts. Then plan a route or run a System Finder search and watch: the calculation sends nothing, and no request anywhere carries your start system, your destination, your search text or the system you clicked. Filter the Network tab by WS and you will find one WebSocket with messages flowing in only. The Application tab shows your preferences in local storage, the kill history in IndexedDB and the cached databases, all of them deletable. Load My Geography and look again: the clones and items you just loaded are not in any of those stores, because they only ever existed in the page. The requests you will see are the ones to CCP's own hosts plus one of this site's own files, the item name and category catalog that turns type numbers into readable names; it is the same file for every visitor and a plain download, so nothing of yours goes out with it. Nothing personal is uploaded anywhere. If you ever find a request that contradicts this page, tell me on the Discord linked in the app's Help panel, and I will either explain it or fix it.

Frequently asked questions

Keeping this page honest

If how the map works changes, this page changes with it, and the Data and privacy section of the in-app Help panel is kept in step so the two never disagree. Everything above was checked against the source code on 2026-08-29.

Related pages

• Privacy, the formal account of analytics, local data and the EVE login.
• Frequently asked questions about the map as a whole.
• About EO-Map, what the project is and how it is run.
• All EO-Map features, one card per tool.