How Live Flight Tracking Actually Works: ADS-B, Explained for Developers

World Eye — Sat, 14 Nov 2026 20:58:18 +0000

Open any live flight tracker and you'll see ten thousand aircraft moving smoothly across a map, each labelled with a callsign, altitude, speed and destination. It looks like the planes are reporting to the website. In a sense they are — but not to the website, and not over the internet. Every one of those dots is an aircraft continuously shouting its own position into the sky on a radio frequency, and anyone with a ~$30 receiver can hear it.

That system is called ADS-B, and understanding it explains almost everything about how flight tracking works: why coverage is brilliant over Europe and patchy over oceans, why some aircraft vanish, and what you actually have to build if you want to render that firehose on a globe. I run WorldEye, where live flights are one layer on a real-time globe next to cameras, satellites and weather — this is the mental model I wish I'd had before wiring that layer up.

ADS-B: the aircraft does the broadcasting

ADS-B stands for Automatic Dependent Surveillance–Broadcast:

Automatic — it transmits on its own, no interrogation needed (unlike classic radar, where a ground station pings the aircraft).
Dependent — it depends on the aircraft's own navigation systems. The plane works out where it is from GNSS (GPS and friends), then broadcasts that answer.
Surveillance — air traffic control uses it to watch traffic.
Broadcast — it's one-way and unencrypted, addressed to nobody in particular.

Roughly once or twice a second, an equipped aircraft transmits a short packet on 1090 MHz (Mode S Extended Squitter). A typical position message contains:

the aircraft's ICAO 24-bit address (a unique airframe ID, e.g. A0F9D2),
latitude / longitude (encoded in a compact format called CPR — more on that below),
barometric altitude, ground speed and track,
vertical rate and a squawk code.

Separate message types carry the callsign ("UAL123") and aircraft category. Notice what's not in there: departure and destination airports. Trackers get route information from entirely separate schedule/airline databases and match it to the callsign — which is why the route line is occasionally wrong while the position is dead-on.

The CPR trick: positions come in pairs

The lat/lon encoding is the first genuinely interesting engineering detail. To save bits, ADS-B encodes position in Compact Position Reporting: a message by itself only narrows the position down to a grid cell. You need an even frame and an odd frame (the two interleaved grid types), received within a few seconds of each other, to decode an unambiguous global position.

Practical consequence for anyone building a decoder or consuming a feed: a single packet is not a position. Your pipeline has to pair frames per aircraft, expire stale halves, and handle the local-decode shortcut (if you already know roughly where the aircraft is, one frame plus a reference position is enough). Get the pairing wrong and you'll see aircraft teleport thousands of kilometres — a classic first-week bug.

From radio waves to your browser: the aggregation layer

Nobody runs a flight tracker off one receiver. Line-of-sight at 1090 MHz from an aircraft at 38,000 ft reaches roughly 400 km; from a rooftop antenna, far less. The live map exists because of aggregation networks:

Crowdsourced receivers. Thousands of volunteers run cheap SDR receivers (an RTL-SDR dongle and a Raspberry Pi will do) and feed what they hear to aggregator networks. Some aggregators publish open data back — the OpenSky Network is the research-friendly example.
MLAT for the gaps. Older transponders don't broadcast position at all — they only reply when interrogated. If four or more receivers hear the same reply, the network can locate the aircraft by multilateration: tiny differences in arrival time turn into a position. That's why some aircraft in a feed have noticeably jumpier tracks — they're MLAT-derived, not ADS-B.
Satellite ADS-B for oceans. Ground receivers can't cover mid-Pacific. A newer generation of space-based receivers listens from orbit, which is how oceanic flights stopped disappearing from trackers.
Cleaning and state tracking. The aggregator (or you, if you consume raw messages) maintains a state table per ICAO address: last position, velocity vector, last-seen timestamp. Aircraft that haven't been heard from in ~30–60 seconds get dropped or greyed out. Between updates, positions are dead-reckoned — extrapolated along the velocity vector — which is why planes glide smoothly instead of jumping once a second.

By the time data reaches a web app, it's usually a JSON snapshot or stream like:

{
  "icao24": "a0f9d2",
  "callsign": "UAL123",
  "lat": 40.6413, "lon": -73.7781,
  "altitude_ft": 35000,
  "velocity_kts": 452,
  "track_deg": 84,
  "vertical_rate_fpm": 0,
  "last_seen_s": 3
}

Rendering 10,000 moving planes without melting the browser

The front-end problem is its own article, but the short version from building this on a MapLibre globe:

Don't create a DOM element or a map feature per aircraft that you update naively every second. Keep aircraft in a single GeoJSON source (or a custom WebGL layer) and update the whole buffer at a throttled cadence — 1–2 updates/second is plenty given dead reckoning.
Interpolate on the client. Store position + velocity + timestamp, then let the render loop extrapolate. The data updates correct the path; the eye never sees steps.
Rotate the icon by track_deg, colour by altitude band, and cluster or cull at low zoom — at world zoom, individual icons are noise; a density view is more honest.
Expire aggressively. A plane that landed and stopped transmitting should fade, not sit frozen on the runway forever.

Why planes disappear (and why that's expected)

Coverage holes: no receiver in range and no satellite pass = no data. The aircraft is fine; the network is blind.
Blocked aircraft: owners can ask aggregators to suppress their tail number (programmes like LADD in the US). The broadcast still happens — the aggregator just won't show it to you.
Military and sensitive flights often transmit partial data or none.
MLAT geometry: with fewer than four receivers in earshot, a non-ADS-B aircraft simply can't be positioned.

A good tracker is honest about this: showing "last seen 42s ago" beats pretending the extrapolated dot is truth.

If you want to explore this yourself

You don't need permission or an API key to start. An RTL-SDR, a small 1090 MHz antenna and open-source decoder software (dump1090 and friends) will put real aircraft over your own house on your screen in an evening — it's one of the most satisfying weekend builds in radio. From there, open aggregator APIs let you prototype against live global data before you ever maintain a receiver.

And if you just want to see the finished picture — ADS-B flights sharing a globe with satellites, weather and 74,229 live public cameras — that's exactly the layer stack at worldeye.app. Open the flights layer, click any dot, and remember: what you're looking at started as a plane shouting its GPS position into the sky, twice a second, to anyone listening.

Questions or corrections? I build WorldEye in public and I'm happy to go deeper on any part of this pipeline in the comments — especially the CPR pairing and the rendering side.

Building WorldEye: Bringing 74,000+ Live Cameras and Global Intelligence Together

World Eye — Sat, 14 Nov 2026 20:04:47 +0000

The world generates an incredible amount of information every second. Aircraft move across continents, weather systems develop, wildfires spread, earthquakes occur, and millions of cameras capture what’s happening in cities and locations around the globe.

But accessing this information often means switching between dozens of different websites and tools.

That’s the problem I wanted to solve with WorldEye.

🌎 https://worldeye.app

What is WorldEye?

WorldEye is a browser-based global exploration and real-time intelligence platform that brings multiple sources of public information together in one interactive experience.

Instead of navigating separate applications for cameras, aircraft, satellites, weather, and natural disasters, users can explore these different layers through one platform.

Some of the features include:

74,000+ public live cameras: Explore live camera feeds from locations around the world.
Aircraft tracking: Follow aircraft movements across the globe.
Satellite tracking: Explore satellite activity and movements.
Weather radar: Monitor weather systems and changing conditions.
Wildfire monitoring: Discover active wildfire activity.
Earthquake tracking: Explore seismic activity around the world.
Transportation: Access transit and transportation information.
Interactive 3D globe: Explore locations and information through a unified geographical interface.

Why build something like this?

One of the biggest opportunities in technology is making complex information easier to access.

Geospatial intelligence, public camera feeds, transportation data, and environmental monitoring are useful across many different industries.

For example:

Travelers can check road and destination conditions.
Researchers can explore locations and global activity.
Weather enthusiasts can monitor developing storms.
Technology enthusiasts can explore aircraft and satellites.
Businesses can use global information to better understand changing conditions.

I wanted to create a platform where these capabilities could exist together.

Where WorldEye is heading

WorldEye is an evolving project. I’m continuing to expand its capabilities, improve the user experience, and explore additional data sources and intelligence tools.

Some areas I’m particularly interested in include:

More real-time global data integrations.
Advanced geospatial intelligence.
Historical camera recordings and monitoring.
Custom alerts and notifications.
Additional transportation and environmental data.
More powerful tools for researchers and businesses.

I’d love feedback from developers

I’m interested in hearing from developers, geospatial engineers, API providers, OSINT enthusiasts, and anyone working with real-time data.

What other data layers would you integrate into a platform like this?

What APIs, open-source projects, or technologies would you recommend exploring?

Are there interesting applications for combining live camera feeds with geospatial intelligence?

I’m actively developing WorldEye and would love to hear what the developer community thinks.

Explore WorldEye: https://worldeye.app

Let’s make the world easier to explore. 🌎

DEV Community: World Eye