| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| # | Callsign | ICAO | Altitude (ft) | Speed (kts) | Last contact | Copy |
|---|---|---|---|---|---|---|
| {{ row.rank }} | {{ row.callsign }} | {{ row.icao24 }} | {{ row.altitude }} | {{ row.speed }} | {{ row.lastSeen }} |
|
| No flights found for the current query. | ||||||
Aircraft surveillance feeds are collections of short state snapshots: where an aircraft was last seen, how high it was, how fast it was moving over the ground, and whether it looked airborne or on the surface. That matters whenever you need a quick operational picture, because the difference between a fresh climb report and a stale ground report can completely change what you think is happening.
This tracker turns that raw feed into a focused lookup. You can search by a callsign-style label, a flight-number-style text string, or a 24-bit hex aircraft address, then scan either a bounded region or the current global feed to pull the freshest matching aircraft state into one readable summary.
It is most useful for short-horizon questions. You might want to confirm that a departure you just heard on the radio is already climbing out, check whether a nearby arrival is still holding, or compare several similar identifiers before you share a position update with a colleague or student. The page gives you altitude, ground speed, vertical trend, heading, last contact time, coordinates, and a short list of alternative matches so that the first result is not a black box.
The boundary is important. This package does not query schedules, route filings, airline timetables, or historical tracks. It reads the current OpenSky state-vector feed and then applies a text match to the returned aircraft fields, so a flight-number-style search works only when that text appears in the reported callsign, and reused or missing callsigns can make a result look more certain than it really is.
Use the output as a live surveillance snapshot, not a guarantee of identity or intent. Public position feeds can lag, coverage varies by region and aircraft, and precise coordinates can still be sensitive when attached to a specific person or operation.
Start with a regional search whenever you already know the rough operating area. The tool converts your center point and radius into a bounding box, which keeps the result set smaller and usually makes it easier to separate one aircraft from a crowded global pool. Global mode is better when you only have a distinctive hex address or you are not sure what region to search, but it also increases the chance of ambiguous text matches.
If you have the hex transponder address, use that first. It is the cleanest identifier in this package because the feed exposes it directly and the page normalizes it to uppercase before matching. Callsigns are still useful, especially for airline traffic, but they can be absent, shortened, reused, or shared by several aircraft over time.
When the identifier returns no hit, the page intentionally falls back to the freshest aircraft in scope instead of leaving you with an empty state table. That behavior is helpful for exploration, but it also means you should read the hint text and matches list before assuming the selected aircraft truly matches your query.
The browser calls OpenSky's /states/all endpoint directly. In regional mode, the page computes a latitude and longitude bounding box from the chosen center point and radius, then sends lamin, lomin, lamax, and lomax with the request. In global mode, those bounds are omitted and the request asks for the full current state list.
Each returned row is normalized into a friendlier object. The package keeps the raw ICAO 24-bit address, callsign, origin country, coordinates, altitude values, on-ground flag, ground velocity, true track, vertical rate, squawk, and position source, then derives display labels in aviation-friendly units. Geometric altitude is preferred when present; otherwise the page falls back to barometric altitude. Ground speed is converted from meters per second into knots, miles per hour, and kilometers per hour, while vertical rate is converted into feet per minute.
| Field | What it means here | How the page uses it |
|---|---|---|
| Callsign | The reported aircraft identifier from the state vector. It may be blank. | Used in the summary, status table, and text matching. |
| ICAO hex | The unique 24-bit transponder address shown as hexadecimal text. | Used as a strong match key and as a fallback identifier when no callsign is present. |
| Origin country | A country inferred from the ICAO address block, not a route origin or destination. | Displayed for context and included in the match haystack. |
| Altitude | Shown in feet, with the source marked as geometric or barometric and meters retained in the label. | Helps separate airborne traffic from surface or low-level movement. |
| Ground speed | Velocity over ground, not indicated airspeed. | Used in the status summary and as a secondary sort tie-breaker. |
| Vertical rate | Climb or descent trend in feet per minute. | Displayed with sign so you can distinguish climb from descent quickly. |
| Heading | True track in degrees clockwise from north, plus an 8-point cardinal label. | Used for quick direction checks in the summary and table. |
| Last contact | The last time any valid transponder message updated the state. | Drives freshness sorting and helps you judge staleness. |
Matching is intentionally simple and therefore important to understand. The query string is trimmed, uppercased, and checked as a substring against a combined search field built from callsign, ICAO hex, squawk, and origin country. The package then sorts the candidate pool by most recent last_contact, with faster ground speed as the next sorter, trims the list to the result cap, and focuses the first row as the selected flight.
That means the page is very good at turning a noisy live feed into a manageable shortlist, but it is not doing airline timetable resolution or route inference. If your input text matches nothing, the page still shows the freshest aircraft in scope and flags that fallback in its hint line. If your input matches several rows, it tells you how many matched and still focuses the freshest one first.
| Source label | Meaning |
|---|---|
| ADS-B | Position derived from Automatic Dependent Surveillance-Broadcast data. |
| ASTERIX | Position coming through the ASTERIX surveillance data format. |
| MLAT | Position estimated by multilateration rather than direct ADS-B coordinates. |
| FLARM | Position reported through FLARM-compatible surveillance data. |
The visible outputs are operational rather than decorative. Status condenses the focused aircraft into copyable rows and a DOCX or CSV export. Map plots only the selected coordinate and offers direct links to OpenStreetMap and Google Maps. Matches keeps the shortlist available for reselection, copying, CSV export, or DOCX export. JSON packages the normalized query context, selected flight, kept matches, fetch time, and source URL into a downloadable record.
Network behavior is straightforward: the page talks to OpenSky from the browser, and the map loads OpenStreetMap tiles only when needed. There is no historical storage layer in this package, no route reconstruction, and no server-side helper that cleans or enriches the flight data before you see it.
The most reliable reading comes from combining freshness, motion, and scope. A high altitude, strong ground speed, and recent contact usually describe an actively airborne flight. A selected row with an On ground flag, slow speed, or an old contact time may instead describe a parked aircraft, a taxiing aircraft, or a stale state that has not been refreshed yet.
If the summary feels slightly wrong, trust that instinct and open the matches table. The package is explicit about ranking by freshness, so the first result is the freshest matching state it kept, not necessarily the aircraft you had in mind when the identifier is broad.
Suppose you hear a departure using a callsign like DAL84 and want to know whether it has already climbed out. Set the center near the departure airport, keep the radius tight, and search the callsign. If the summary shows a recent contact, a positive vertical rate, and a heading that makes sense for the local procedure, you have a useful live snapshot without needing a route database.
Now imagine a broader search returns several airline-style identifiers that share the same prefix. The shortlist becomes the decision tool. Compare ICAO hex, altitude, speed, and last contact time, then use the focus button in the matches table to step through each candidate until one lines up with the movement you expect.
If you already have the aircraft's hex address from another receiver or spotting log, enter that instead of a callsign. Because the package matches hex directly and the address is unique to the transponder, the result is usually less ambiguous than a text search built around an airline identifier.
Only the latest kept state for each match. The map is a last-seen marker, not a historical trail.
When the query finds no substring match, the package falls back to the freshest aircraft in scope and tells you that in the hint text. That behavior is useful for discovery but it is not an exact-lookup guarantee.
You can search by flight-number-style text, but the page is still matching the reported callsign field from the live state feed. If the feed does not expose that text, the query will not behave like a schedule database lookup.
The source defines it from the ICAO 24-bit address block. It is not a departure point, destination, or proof of current operator nationality.
Live surveillance data changes quickly, rate limits apply, and a broad or ambiguous query can keep surfacing different aircraft as the freshest match. Narrowing the region or switching to a hex address usually helps more than polling faster.