Privacy

EO-Map is a free map of New Eden that runs in your browser. This page describes what is measured, what stays on your own machine, and what leaves the site when you follow a link. It is written to match what the app actually does, and the same account of it appears in the Data and privacy section of the in-app Help panel.

Analytics

Site traffic and usage are measured through three channels, and all three are aggregate only. They exist so the project can tell how the service is used and improve it, including the standard monthly usage evidence EVE Online's partner programme asks a fansite to show. They are not used for advertising, remarketing, Google Signals, cross-site tracking, or building a profile of you as a person.

Cloudflare Web Analytics runs across the whole site; it is cookieless, stores nothing on your device, and reports aggregate figures only. It is enabled at the hosting level and is not switched by the control below.

Google Analytics runs on the map application itself, and only on the production map. It uses its standard first-party cookies on eo-map.com to tell a returning browser from a new one, which is what makes daily and monthly visitor counts possible. Advertising storage, advertising user data, ad personalisation and Google Signals are switched off in that configuration. Google is used only to produce those statistics for EO-Map. 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. Reports are aggregates: page views, sessions, referrers, country and browser type.

The third channel is EO-Map's own usage counters, which run in the map application and, since 2 September 2026, on the blog pages as described below. The map sends small anonymous batched events to an EO-Map service, each one a fixed event name plus, where an event needs it, a small allow-listed category such as which tool or map layer, a simple on-or-off flag, or a number already rounded into coarse buckets before it leaves your browser. They record which tools get opened, which map layers get switched on or off, which layout you switch to and how (Watch view or Map view, by button, key, first-visit default or link), which Watch view feed filters, feed cards and system page controls get used, 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. They carry no cookie, no visitor or session identifier, no character name or id, no route or its start and end systems, no search text, no system you clicked or viewed, no coordinates, no My Geography data and no free text, and the service adds them straight into daily totals, so there is no per-visitor anything behind them.

The blog pages count one thing, and it is the only measurement any page outside the map application carries beyond Cloudflare's. When a blog page loads, it sends EO-Map's own analytics service a single message containing the article's slug and nothing else. There is no cookie, no visitor or session identifier, no referrer, no title, no reading time and no scroll depth in it, and your IP address is not stored: the service reads the connecting address only to hold a short-lived rate limit in memory, and it is never written down. What the service keeps is one number per article per day, added straight into the same daily totals as everything above. It exists so the project can see which articles are still worth updating. Because nothing identifies a visitor, these are page loads rather than readers, and reloading an article counts again. The same Usage statistics preference that stops Google Analytics also stops these blog counts and the map's own usage counters.

How to turn this off. Google Analytics and EO-Map's own usage counters are on by default. You can object at any time, for free, and the map works the same either way. The quiet place in the app is Display Settings on the map (Interface, then Usage statistics). The control below does the same thing. Turning it off stops Google Analytics on this browser: the script is not loaded, events are not sent, and the analytics cookies are deleted. It also stops EO-Map's own anonymous usage counters, including the blog page-load count. Offline Mode does the same for the map. Cloudflare's cookieless measurement is separate and is not controlled here.

You can also open Display Settings on the map.

Beyond those channels, no other measurement runs on the site. There are no marketing scripts, no third-party tracking pixels and no cross-site identifiers. The other discovery pages carry only the Cloudflare measurement.

What stays in your browser

EO-Map has no account of its own, so there is nothing to sign up for and no profile held anywhere. The map, its databases and its tools all run in the page itself. You may optionally connect an EVE Online character, which is covered in its own section below.

Your preferences live in this browser's own local storage: panel positions and which panels you have pinned, display and performance settings, accent colour, language, overlay choices, whether you have turned usage statistics off, the systems you have marked as visited, and the last hundred commands you ran in the Ctrl+K command palette, so the up arrow can bring them back. Routes, waypoints, avoid lists and filters are calculated on your own machine and are never uploaded. Downloaded map databases are held in the browser cache so they do not have to be fetched again on your next visit. Exporting display settings as JSON does not include the usage-statistics preference.

Watch view, the layout for big monitors, adds a few items to that local storage. Your choice between Watch view and Map view is kept under eo:layout-view:v1. Only a deliberate switch writes it: the view button, the T key, a What's new row for Watch view, or Use Map view on the note shown when Watch view does not load. The Recent chips on the system page keep, by id, the last six systems you selected while Watch view was showing, under eo:watch-recent-systems:v1. The tools you have opened, in either view, are listed under eo:tools-tried:v1, so the feed can suggest ones you have not tried yet. The live card's event filters and its Live and News switches are the tickers' own saved settings (ef_event_filters, ef_event_filter_min_isk, ef_live_events_enabled and ef_news_ticker_enabled), so one choice holds in both views. Two markers sit in session storage and are gone when you close the tab: eo:watch-view-retry records when a Watch view that failed to load was retried, and eo:watch-view-enter-owed marks a switch to Watch view that has not finished loading, so the usage counts stay balanced if it never does. The feed's chosen filter and scroll position are held in the page's memory only and are forgotten on reload. None of these items is sent anywhere. The system page and the feed read the same public snapshots the map already uses, and Watch view makes two kinds of request the map does not otherwise make, neither carrying anything about you. For a busy system, the Kills chart asks EO-Map's killboard service for that system's last seven days of public killmails, the same request Kill Replay makes, carrying the system id, a time window and a page number, and nothing about you. When the service has to fetch them from zKillboard, it adds one to a daily count kept under a SHA-256 hash of your IP address, which expires after two days; every request, cached or not, counts toward a one-minute rate limit keyed by the same hash. And the feed's pictures load directly from each source's own image host: YouTube's i.ytimg.com for video thumbnails, Reddit's i.redd.it, preview.redd.it and external-preview.redd.it, Twitch's static-cdn.jtvnw.net, and the official news site's and forums' image hosts, images.ctfassets.net and global.discourse-cdn.com. They are requested with no referrer, and each of those hosts sees your IP address the way any image host does. Blog pictures come from eo-map.com itself. Watch view's three usage events are part of EO-Map's own counters described above: they say which layout was switched to and how, which feed filter or card was used and which system page control was pressed, they carry no system id or name, and the same Usage statistics preference stops them.

One thing does not even reach that storage. If you use My Geography, the clone and item data it loads lives only in the page's own memory: it is never written to browser storage of any kind and never sent to an EO-Map server, and it is gone as soon as you reload or close the tab. The section below covers it in full.

All of it is yours to remove. Clearing this site's data in your browser resets EO-Map to a first visit, and Display Settings carries its own reset for the sliders and toggles in that panel. You can also export those settings as a file and import them on another device, which is the only way anything moves between your browsers.

Beyond the measurement described above, some things do involve the network by design. The map data and the public overlays are fetched as files when the map loads; the live event feed is an open connection that pushes killmails and sovereignty changes to you as they happen; and if you open the Market History or Trade Routes panel, your browser asks EVE Online's official public data service (ESI) directly for regional trade history: in Market History for the item and regions you pick, and in Trade Routes for the destination region of the route on screen, which it shows as soon as it opens. That is a public lookup with no login attached, and nothing about you is reported to EO-Map. Watch view adds two, described above: the Kills chart's lookup on EO-Map's killboard service, and the feed's pictures from their sources' own image hosts. All of them send data to your browser rather than collecting it from you, and the connected maps figure shown in the app is a count of open map connections, not of unique people.

The optional EVE Online login

EO-Map can optionally connect to your EVE Online character, and nothing that existed before that feature requires it. The control sits in the top bar of the map on desktop, it is absent from any embedded or framed view of the map, and if you never use it the map behaves exactly as it always has.

The login itself runs on CCP's official EVE Online SSO pages, so EO-Map never sees your account name or your password. The login has no EO-Map account server behind it: the token CCP returns is held in this browser's local storage and sent only to CCP's own hosts, login.eveonline.com and esi.evetech.net. It is never put in a share link or a URL, and it is never attached to an analytics event. One narrow exception exists and it applies to the site owner alone: when the owner opens the site's private usage dashboard, the owner's own short-lived token is sent to an EO-Map service once per request so the service can confirm the request really comes from the owner. That token is not stored or logged there, refresh tokens never leave the browser, and no visitor's token is ever sent to EO-Map infrastructure. Your character name and character id are not measured and not reported anywhere.

Your character portrait is loaded from CCP's image service at images.evetech.net, which sees your character id and your IP address the way any image host does. The token is never sent there, and nothing about that request reaches EO-Map.

The ordinary login asks for one permission: setting autopilot waypoints in your running client, the ESI scope esi-ui.write_waypoint.v1. It is used only when you click Set Destination on a calculated route. Anything beyond that is asked for one permission at a time, by the feature that needs it, and each is a separate consent on CCP's own pages. Personal route checks can 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. The My Location readout can ask for your last reported system, esi-location.read_location.v1, only when you press it. My Geography can ask for your clone locations, esi-clones.read_clones.v1, your item list, esi-assets.read_assets.v1, and the player structures you can dock at, esi-universe.read_structures.v1, only when you choose those sections. Security status and militia affiliation come from the public character sheet and do not need a scope. Your contacts, your mail and anything to do with your money are never asked for at all, and six scopes that exist on EO-Map's registration are never requested by any feature, including the one for character contracts. Everything these grants return stays in this browser. None of it is written to exported preferences, sent to EO-Map, or attached to analytics.

My Geography holds the most personal of that, so it is kept the most tightly. Nothing loads until you have allowed a section on CCP's pages, and after that a section loads when you open the panel, never in the background. The clone and item rows your browser gets back from CCP, the player structures it looks up, and the systems, totals and estimated values worked out from them, live only in that page's memory. They are not written to local storage, session storage or IndexedDB, they are never put in a link you can share, and they never reach an EO-Map server, an analytics event or a log. Reloading the page or closing the tab loses them, and they load again the next time you open the panel. Clearing the panel, logging out, switching character or a login that has stopped working clears them as well. The login token is the one thing that does persist in this browser, and it is not the same thing as the data.

Intel, a controlled public beta, is the first EO-Map feature with a durable personal store. A pasted Local member list or directional scan is read at once, and when the system is known, from your EVE location, your map selection or a system you pick, it is saved straight away with an Undo for 60 seconds. Two switches in the panel's Settings tab, both on by default, control that separately for Local lists and for D-scans. With no known system nothing is saved until you pick one and press Save. A save writes the parsed rows, the report they came from and compact evidence records to this browser's IndexedDB under the name eo-intel. The raw pasted text is never stored: it is held in the page's memory only, for that Save button, until your next paste or a reload. Detailed rows are kept for one year by default, adjustable in Settings; the compact evidence records and per-name summaries stay until you delete them, so your counts remain exact after old rows expire. A browser without IndexedDB, such as a private window, runs Intel for the session only and tells you so. Reports can be retracted or deleted from the panel's History tab; Settings offers export, import with a preview and an undo of the last import, Clear detailed history (which keeps your counts) and Delete all Intel data behind a typed confirmation.

The public lookups are on by default for pasted member lists and can be switched off in Settings, and a name you look up on the Lookup tab goes through the same calls. Your browser sends the names, and nothing else, to EVE's public API (ESI) directly to resolve characters, corporations and alliances, and when you open a dossier it asks ESI for that character's public profile and corporation history by character id. The answers are cached here; this is the same kind of direct public call Market History makes. Intel then asks EO-Map's own killboard service, a small Cloudflare Worker EO-Map runs, for the public record of each resolved character, including zKillboard's own character labels: your browser sends a character id and nothing else, with no login and nothing about you attached, and the service answers with statistics it collected from zKillboard on the server side with its own caching, so your browser never contacts zKillboard at all. Those answers are cached in the same IndexedDB and expire on their own. If you are signed in with an EVE character, Intel also asks ESI's public affiliation endpoint for your own character's corporation and alliance, so it can show pilots on your side as Friendly: that request sends your character id and no token, and the answer is kept in the page's memory only. Pilot portraits and corporation and alliance logos are loaded from CCP's image service at images.evetech.net, which sees those ids and your IP address the way any image host does. The zKillboard and EVE Who links in a dossier are plain links, so those sites see nothing from Intel unless you open one. Typing a pilot name into the map's search box sends nothing until you choose Look up in Intel. Your last eight lookups (name, character id and time) and the pilot list's Compact or Detailed choice are kept in this browser's local storage, and Delete all Intel data clears the lookups. Nothing from Intel reaches an analytics event.

Kill Replay reads public killmails through the same EO-Map killboard service. To build a replay your browser sends it the id of the pilot, corporation, alliance or solar system you picked and the time window, with no login and nothing about you attached, and the service answers with trimmed killmails it collected from zKillboard on the server side, so your browser never contacts zKillboard. A name you type is sent to EVE's public API to find its id, and the names shown in a replay are resolved there too. Pressing Me uses your signed-in character's id the same way and sends no token. The kills are held in the page's memory only and are gone when you reload. Your last six subjects and whether you turned the music on are kept in this browser's local storage. A copied replay link carries the subject, the window and the fight, and nothing else. The zKillboard links in a replay are plain links, so zKillboard sees nothing from Kill Replay unless you open one.

The Killboard's front page and leaderboards are one snapshot file that your browser fetches like any other EO-Map snapshot, the same file for every visitor. Opening a profile sends the same EO-Map killboard service the kind (pilot, corporation or alliance), the id and the period, with no login and nothing about you attached, and the service answers with figures it worked out from its own copy of zKillboard's feed, cached for a few minutes so that everyone opening the same profile shares them. Typing into the search field sends what you typed to that service, which answers from an index; EO-Map does not log the query; pressing Enter on a name the index does not know sends that exact name to EVE's public API. Pressing You uses your signed-in character's id the same way and sends no token. Portraits, logos and ship renders load from CCP's image service at images.evetech.net, which sees those ids and your IP address the way any image host does. The All time section at the end of a profile asks zKillboard's statistics through the same EO-Map service, so zKillboard sees EO-Map's request, not yours. The Killboard keeps nothing in your browser's storage, and the zKillboard links on it are plain links.

You can connect more than one character, and each character's token is stored separately in this browser, up to 100. A character you are not using is never refreshed or read in the background; only the active character's token is used. Switching character clears the My Location and My Geography data loaded as the previous one. Removing a character asks CCP to revoke its token and then deletes it from this browser whether or not that request succeeds, and never touches your other characters. You can also review and revoke access at any time from CCP's own page at developers.eveonline.com/authorized-apps, which is the authority whatever any application shows you.

What EO-Map does not do

Outbound links

Some parts of the map deliberately send you elsewhere. Clicking an event in the live ticker opens that killmail on zKillboard in a new tab, and the Help panel links the project community channels. Those destinations are not run by EO-Map, and once you follow the link you are on their site under their own privacy terms.

EO-Map does not attach anything about you to an outbound link. A killmail link carries the identifier of the killmail you clicked and nothing else. The same is true of these discovery pages, which link only to other EO-Map pages and to the map itself.

Changes

If what is measured 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. A material change to what is measured is recorded on this page and in the transparency report, and the update dates on both show when it happened. The date below is the last time this page was reviewed against what the site actually does.

Last updated 2026-11-05, when the Watch view paragraph under What stays in your browser gained a sentence on what EO-Map's killboard service keeps for the Kills chart's lookup: when it has to fetch the kills from zKillboard it adds one to a daily count kept under a SHA-256 hash of your IP address, which expires after two days, and every request, cached or not, counts toward a one-minute rate limit keyed by the same hash. Before that, 2026-11-04, when Watch view, the layout for big monitors, added its browser storage items to What stays in your browser, its two kinds of request (the Kills chart's lookup on EO-Map's killboard service for a busy system, and the feed's pictures from their sources' own image hosts, which see your IP address) to the network paragraph, and its three anonymous usage events to the list of what the map counts. Before that, 2026-09-27, when Trade Routes joined Market History as a panel that asks EVE Online's public data service directly for regional trade history, for the destination of the route it shows. Before that, 2026-09-15, when Google Analytics on the production map was configured for statistical use only (no advertising, no Google Signals, no remarketing), and a persistent Usage statistics control was added under Display Settings → Interface and on this page so you can object. Objecting stops Google Analytics from loading, stops EO-Map's own usage counters including the blog page-load count, and deletes the analytics cookies on this browser. Cloudflare's cookieless measurement is unchanged and is not switched by that control. Before that, 2026-09-08, when the Analytics section distinguished iframe embeds (still a page of eo-map.com, so Google Analytics records a page view) from the native JavaScript embed (which does not inject Google Analytics or EO-Map's own usage counters into the host page). Before that, 2026-09-07, when the Analytics section was made explicit that a chrome-free embed of the map on another site still records a Google Analytics page view. Before that, 2026-09-02, when the blog pages began sending an anonymous per-article page-load count to EO-Map's own analytics service, described in the Analytics section above. Before that, 2026-08-29, when EO-Map's own anonymous usage counters were added as a third measurement channel, the login-token rule gained its one exception, the site owner's own token verifying the owner for a private usage dashboard, and the promise to announce measurement changes in the app was dropped in favour of recording them here with the date. Later the same day the counters started recording map-layer toggles alongside tool usage, and this page was corrected to say that some events carry a small allow-listed category or an on-or-off flag as well as bucketed numbers. Before that, 2026-08-28, when My Geography added optional clone and item permissions that are read into the page and never stored or uploaded, and 2026-08-21, when Google Analytics was added alongside Cloudflare Web Analytics and the optional EVE Online login was introduced.

Related pages