hexdb.io: Intelligence Source Guide

hexdb.io is the free Mode-S lookup service that most community ADS-B receiver installations call in the background: hex to registration, type, operator and registered owner, plus callsign to route and airport detail. It is quiet infrastructure worth understanding before you rely on it.

At a glance

Source	hexdb.io
Category	Aviation & Space › Aircraft, Airports & Safety
Homepage	https://hexdb.io
Machine interface	`https://hexdb.io/api/`
Format	`JSON`
Access	Open — no account required
Disciplines	Aviation Intelligence
Mission domains	Aviation Security

Free Mode-S/ADS-B API converting 24-bit ICAO hex to registration/type/operator, and callsign to route and airport info. — as catalogued in the platform’s own source registry.

hexdb.io is a small, keyless HTTP API serving three related lookups against a compiled aircraft and airport dataset. The aircraft lookup takes a 24-bit Mode S address and returns the registration, ICAO type code, a longer type string, manufacturer, an operator field, an operator flag code used for livery selection in mapping software, and a registered owners field. The route lookup takes a callsign and returns the airport pair or sequence associated with it. The airport lookup takes a location indicator and returns the airport's name, country and position. Responses are flat and compact, which is a design choice reflecting the service's real workload: it exists primarily as the enrichment backend for community ADS-B map software running on thousands of small receivers, where a hundred lookups a minute have to be cheap. Field names differ between the three endpoints and have changed over the service's life, so read a live response rather than coding against remembered key names.

Two things distinguish this from the other free resolver in the catalogue. The first is that it separates operator from registered owner as distinct fields, which sounds like a detail and is actually the most analytically useful thing about it. An airliner leased from a lessor and operated by a carrier has two different correct answers to who owns it, and a source that returns both lets you see the leasing relationship rather than flattening it. The second is that its data lineage runs through the aircraft database tradition that grew up around receiver software rather than through a modern rebuild, which means it sometimes carries entries that newer compilations have dropped and sometimes carries entries that are ten years out of date. Neither property makes it better or worse than the alternative; it makes it different, and difference is the point. Running two independently maintained resolvers over the same identifiers is the cheapest quality control available in aviation analysis, and this is the second resolver.

Who publishes it, and why that matters

The service is maintained by an individual within the ADS-B receiver community and is provided free with no published service commitment. Its position in the ecosystem is unusual: because popular receiver map software calls it by default, it carries continuous load from a very large installed base of hobbyist receivers that its maintainer neither controls nor bills. That gives it a strange reliability profile. It is well exercised and generally up, because a great many people would notice immediately if it were not, and it is simultaneously a single point of failure for a substantial part of the community tooling stack with no redundancy behind it. There is no funding model, no support channel with an obligation attached, and no published continuity plan. Plan accordingly: cache locally, keep an alternate resolver configured, and do not design a workflow whose failure mode is a wave of unresolved aircraft when one person's server has a bad afternoon.

Provenance is the first question to ask of any dataset and the one most often skipped. Who collects it, what their incentive is, whether they publish a methodology, and whether they correct the record when they get something wrong all bear directly on how much weight a finding drawn from it can carry.

What a record actually contains

The fields you will be working with, what each one means, and whether it is something you can pivot on. Read the meanings carefully — more analysis is wrecked by misreading a field than by failing to find one, and a field that looks like an observation is often an inference.

Field	Type	What it means	Pivot value
`ModeS`	string	The 24-bit ICAO transponder address in hex, used as the lookup key. Allocated by the state of registry, so it changes when an airframe is re-registered to another country.	ADS-B tracks, datalink records, national registry, state-of-registry allocation block.
`Registration`	string	The civil registration mark associated with that address in the compiled dataset. This pairing is the field most likely to be stale after a sale or re-registration.	National registry search, ownership research, incident and maintenance history, photography.
`ICAOTypeCode`	string	The controlled ICAO type designator. Short, stable and the correct field to join on when merging fleet data across sources.	Aircraft performance category, role inference, flight plan and schedule data.
`Type`	string	A longer human-readable type and variant string. Formatting is inconsistent across the dataset and it is not a controlled vocabulary, so do not group on it.	Human interpretation and plausibility checking only.
`Manufacturer`	string	Airframe manufacturer as recorded when the entry was created, which means it reflects historical corporate names rather than current ones.	Export control classification, fleet composition analysis, supply chain work.
`Operator`	string	The party operating the aircraft, where the dataset records one. Distinct from the registered owner and frequently the more operationally relevant of the two.	Carrier entity, air operator certificate research, wet-lease and codeshare analysis.
`RegisteredOwners`	string	The party holding the registration. For leased airliners this is often a lessor or a special purpose vehicle; for business aircraft it is often a trust or bank.	Corporate registry, beneficial ownership research, sanctions and export control screening.
`OperatorFlagCode`	string	A short code used by receiver mapping software to select a livery or flag image. It is a display convention inherited from receiver software, not an authoritative operator identifier.	Operator hypothesis only; never use as an identity key.
`callsign`	string	The flight identifier submitted to the route endpoint, in the ICAO form that appears in transponder broadcasts rather than the IATA form used commercially.	Schedule data, operator inference, route hypothesis for track correlation.
`route`	string	The airport sequence associated with a callsign, expressed with location indicators. It describes the route the callsign normally flies, not the flight that was actually operated.	Airport entities, geographic hypothesis to test against an observed track.
`airport name`	string	Plain-language airport name from the airport endpoint. Names in compiled airport data are inconsistent for military, joint-use and renamed fields.	Airport entity, operator and ground handling research, NOTAM and weather lookup.
`country`	string	Country associated with an airport or with a registration, depending on the endpoint. Reflects the compiled dataset's territorial conventions, which do not always match current political reality.	Jurisdiction analysis, overflight and sanctions geography.
`latitude / longitude`	float	Airport coordinates in decimal degrees, sufficient for mapping and distance work but not for anything requiring surveyed accuracy such as runway-level analysis.	Geospatial correlation with tracks, distance and range analysis, imagery tasking.
`elevation`	int	Field elevation, where present. Relevant when reconciling barometric altitude from an ADS-B track against height above the ground at an airport.	Altitude reconciliation, approach and departure profile analysis.

Coverage — and what is not in it

Coverage reflects the receiver community's needs rather than a systematic collection plan. Commercial airline fleets worldwide are well represented, because that is what the receiver community sees most and corrects most. Business aviation is present with variable quality. General aviation coverage is patchy and concentrated in countries with open registries and active spotting communities. Military and state aircraft appear inconsistently and often with generic or dated descriptions. Airport coverage is broad, including small and regional fields, because it derives from open airport compilations with global scope. Route coverage extends to scheduled services with recognisable callsigns and does not meaningfully extend to charter, cargo tramp, ferry, positioning, business or state aviation. Updates arrive as the maintainer refreshes upstream compilations and as community corrections propagate, which is a periodic and unannounced rhythm rather than a scheduled one. There is no historical dimension: you get one current record, with no prior registrations, no ownership history and, on most endpoints, no indication of when the entry was last touched.

Known blind spots

Absence of evidence here is not evidence of absence. These are the conditions under which hexdb.io will not show you something that is nevertheless real:

Entries created years ago and never revisited persist indefinitely, so an airframe that was withdrawn from use, scrapped or re-registered a decade ago can still resolve cleanly to a plausible-looking current record.
The operator field is frequently blank or inherited from an earlier lease, which means the field that would be most useful is precisely the one most likely to be missing or wrong.
Route lookups only cover scheduled callsigns, so charter, ferry, positioning, cargo tramp and government flights return nothing, and those are disproportionately the flights that prompt an investigation.
Aircraft broadcasting privacy or temporary addresses do not resolve at all, and the response does not distinguish a privacy allocation from an unknown aircraft.
There is no last-updated field on the aircraft record, so a fresh entry and a decade-old one are indistinguishable in the response and no downstream logic can tell them apart.
Airport data records position and name but not operational status, so closed, seasonal, restricted and military-only fields resolve exactly like active international airports.
The dataset inherits the territorial and naming conventions of its upstream compilations, which produces country attributions for airports in disputed or recently changed territories that may not match your organisation's position.
Because the service is a single-maintainer free endpoint under heavy background load from receiver software, an outage or throttle presents as a silent enrichment failure across your whole pipeline rather than as an obvious error.
Nothing in the response indicates provenance, so you cannot tell whether a field came from an authoritative registry import, a community correction or an entry typed in years ago.

Write the blind spot into the product. A statement that something “was not observed in hexdb.io” is defensible; a statement that it “did not happen” is not, and the difference is what survives cross-examination.

Access, licensing and what you may do with it

Access model: Open — no account required

Access is an unauthenticated HTTPS GET with the identifier in the path, and the three families are aircraft by Mode S hex, route by callsign, and airport by location indicator. Read a live response before writing a parser: key names differ between endpoints, capitalisation is not uniform, and missing values may be absent keys, empty strings or placeholder text depending on the endpoint. Because this service is called automatically by widely deployed receiver software, the responsible pattern is to behave like a well-configured receiver rather than like a scraper – one lookup per new aircraft, cached for a long time, never a bulk sweep. If your requirement is systematic resolution of a large fleet, do it from your own copy of an open aircraft database rather than through this endpoint. Wire a health check into your pipeline so that a resolver outage surfaces as an alert instead of as an unexplained drop in enrichment coverage.

Licence

There is no prominent formal licence or terms document, which is itself the important fact: the absence of stated terms is not permission, and you should not assume a right to redistribute the dataset or to build a commercial product on top of it. Internal analytical use of individual lookups is the use the service plainly anticipates, since that is what receiver software does all day. Bulk extraction to reconstitute the underlying database is a different act and one you should not undertake without asking. The data itself is downstream of community aircraft compilations and open airport datasets whose own terms vary from public domain to unstated, so a redistribution question has to be resolved at that upstream layer rather than here. If you need clear licensing for a commercial deployment, use an authoritative registry or a commercially licensed aviation dataset, and keep this service for internal triage.

Rate limits and fair use

No published quota, which means the constraint is etiquette rather than a documented number. The service absorbs continuous background load from a large receiver population, and a bulk job from one analyst is a visible and unwelcome addition to it. Cache aircraft records for weeks, cache airports effectively forever, cache routes for a schedule season, and make the network call only on a genuine cache miss. Set a descriptive user agent with a contact address so the maintainer can reach you rather than having to block you. If you observe throttling or errors, back off exponentially rather than retrying tightly; a retry storm from a well-resourced analytical pipeline against a hobbyist server is how free community infrastructure gets taken away from everyone.

Licensing changes, and it changes without warning. A dataset that was free for research this year may not be free for commercial or evidential use next year. Confirm the current terms before you build a dependency on it, and record the terms you relied on alongside the data — the licence in force at the time of collection is part of the provenance.

Collecting it

How hexdb.io is actually pulled, in the order you would set it up. Prefer the bulk or export interface over per-item lookups wherever one exists: it is kinder to the publisher, faster for you, and gives a reproducible snapshot rather than a series of point-in-time answers you cannot reconstruct later.

Method	Format	Cadence	Notes
Aircraft lookup by hex	JSON	on cache miss only; retain for weeks	The main path. Resolve each distinct 24-bit address once, store the result with your resolution date, and re-resolve on a slow rolling cycle.
Route lookup by callsign	JSON	on cache miss; refresh per schedule season	Produces an airport pair for scheduled callsigns. Store as an expectation to be tested, never as an observation of a flight.
Airport lookup by location indicator	JSON	once; refresh annually	Small, stable reference data. Mirror the airports you care about locally rather than querying repeatedly.
Comparative resolution	JSON	on demand for consequential identifiers	Query this and the alternate free resolver for the same identifier and record the delta. The disagreement set is where your registry effort should go.
Local aircraft database mirror	bulk	rebuild when upstream compilations update	For volume work, build from the open aircraft compilations directly. Slower to set up, and the only sustainable approach above light query rates.

Ingesting it into the platform

Every step below is idempotent and cursor-based: interrupt one and it resumes from where it stopped rather than duplicating rows or losing progress. Collection is recorded per source, so a feed that quietly stops publishing shows up as a stale timestamp instead of silently thinning your coverage.

Register as a secondary resolver — Add hexdb.io in sources.php explicitly as the second of two aircraft resolvers, so the catalogue records that the platform deliberately runs redundant enrichment rather than picking one arbitrarily.
Cache before calling — Have enrich.php consult a durable local cache keyed on the identifier before making any network request, and store the resolution timestamp with every entry because the API supplies none.
Resolve identity in parallel — Run resolve-everything.php so that each distinct hex address is resolved through both free resolvers, storing both results as separate attributed claims rather than merging them into one field.
Diff and flag — Compare the two resolutions on registration, type, operator and owner, and raise a data quality flag on the aircraft entity wherever they disagree. That flag is the trigger for registry work, not a defect to be silently reconciled.
Split owner from operator — Preserve the operator and registered owner fields as distinct attributes on the entity. Collapsing them into a single owner field destroys the leasing relationship that is often the reason the lookup was worth doing.
Attach airports as entities — Resolve route and airport responses into airport entities with coordinates, so link-analysis.php can traverse from aircraft to airport to country rather than treating a route as a text string.
Escalate for products — Route any aircraft that will be named in a report through an authoritative registry check and through sanctions screening, and record the registry, the query date and the retrieved record in the case.
Monitor resolver health — Track resolution success rate as a pipeline metric in analytics.php so that a resolver outage appears as an alert rather than as an unexplained decline in enriched aircraft.

Registered sources and their last-collected state are listed in sources.php, and the scheduled chain that keeps them current is in automation.php.

How it is wrong, and how to tell

Every dataset is wrong in characteristic ways. Knowing which ways is the difference between using a source and being used by one, and it is the part of source evaluation most often skipped because it is the part that takes work.

The correct way to judge this source is comparatively rather than absolutely. On mainstream commercial fleets it agrees with the other free resolvers and with registries most of the time, which is what you would expect from overlapping upstream data actively corrected by people who care about airliners. Its distinctive risk is age: the compilation tradition it descends from accumulates entries and does not aggressively retire them, so it carries long-tail records that are correct as history and wrong as current fact. Its distinctive strength is the operator and registered owner split, which preserves information other resolvers discard. Neither the strength nor the risk is visible in any individual response, because there is no provenance, no timestamp and no confidence field. The practical quality method is therefore triangulation: resolve through two services, treat agreement as adequate for triage and disagreement as a requirement for registry work, and never let an unverified field cross the boundary into a finished product. Judged as free community infrastructure it is good; judged as an evidential source it is not one, and it does not claim to be.

Characteristic false positives

Fossil records are the signature failure. An entry written years ago for an airframe that has since been re-registered, re-engined, sold or scrapped returns with full confidence and no indication of its age, which is more dangerous than a missing record.
The operator field can reflect a lease that ended, so an aircraft is attributed to a carrier that has not flown it for years, and the attribution looks authoritative precisely because the field exists and is populated.
Registered owner for leased airliners is the lessor, and reading it as the airline produces a fleet analysis that assigns aircraft to finance companies; reading it as the beneficial owner for business jets produces a trust or bank.
Route lookups return schedules, so diverted, cancelled, substituted and repositioned flights resolve to airport pairs that bear no relation to what happened, with nothing in the response signalling that it is a plan.
Callsign collisions across carriers and across days mean a route can be returned for a flight identifier that was used by a different operator entirely on the day you are examining.
Type strings are free text with inconsistent formatting, so grouping or matching on them silently splits the same type into several apparent variants and corrupts any fleet count.
The operator flag code is a livery selector inherited from mapping software, and using it as an operator key produces attributions that are wrong in ways that are very hard to trace back to their cause.
A null or empty response conflates unknown aircraft, privacy addressing, malformed input and service degradation, and if your pipeline treats all four as unknown you will not notice when the service is quietly failing.

None of these make the source unusable. They make it a source that requires corroboration before an assertion built on it goes into a product, which is true of every source and admitted by few.

Ageing

Records here age silently and without limit. There is no last-updated field, no retirement process visible from outside, and no signal that distinguishes an entry refreshed last week from one created a decade ago. Type and manufacturer never go stale. Registration and hex pairing go stale at re-registration. Operator goes stale at every lease change, which for an active leased fleet is a frequent event. Registered owner goes stale on sale, and that is exactly the transaction asset-tracing work exists to detect. Route data goes stale each schedule season. The practical consequence is that ageing has to be managed entirely on your side: stamp every resolution with its date, set a re-resolution interval short enough that a sale cannot hide in it for long, diff results between resolutions, and treat any change as an event on the entity rather than as a cache refresh. A stale record here looks exactly like a good one, which is why procedure rather than validation is the answer.

What this source feeds

A source is only worth what it lets you conclude. These are the disciplines that collect through it, the mission domains it serves and the data points it yields — every one is a tag, so you can follow any thread from here into the rest of the library.

Collected by these intelligence disciplines

Aviation Intelligence

Serves these mission domains

Aviation Security

Yields these data points

How each sector uses hexdb.io

The same dataset is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The records are shared — the constraints, thresholds and outputs are not.

🎖 Military and defence

Its practical role is bulk triage of a civil air picture: resolving large numbers of observed addresses fast enough that an analyst can focus on the few that matter. The operator field is useful for identifying contracted and leased transport supporting operations, which is a class of activity that shows up as ordinary commercial aviation in a track. It is weak on military registrations and should not be used to characterise state aircraft. Treat it as the second opinion in a two-resolver setup, since divergence between resolvers is often the fastest way to spot an airframe whose identity has recently changed.

🕵 National intelligence

Valuable in AVINT workflows for two specific reasons: it requires no account, so resolution leaves no commercial record of which airframes interest you, and it preserves the operator and owner distinction that reveals leasing structures. Those structures matter, because leasing is a routine mechanism by which aircraft reach operators that could not acquire them directly, and a resolver that flattens owner and operator hides exactly that. The analytical caution is unchanged from any compiled source: resolution generates hypotheses, and the registry, corporate records and sanctions data settle them.

👮 Law enforcement

Useful for rapid identification in live situations and for populating the aircraft entity in a case file, where speed matters more than evidential weight. Neither the operator nor the owner field is evidence, and both should be replaced with registry records obtained through proper process before anything is relied on in proceedings. Where the two free resolvers disagree about an aircraft in an active investigation, that disagreement is worth an analyst's attention in its own right, since it often indicates a recent change of registration or ownership.

🔍 Private investigation and corporate security

The pragmatic second lookup when a first resolver returns something that does not fit. For fleet and leasing questions in corporate work it is often the better of the two, because a lessor named in the owner field with a carrier named in the operator field is a real commercial relationship you can research. The professional discipline is to date every lookup and to tell the client plainly that compiled aviation ownership data lags real transactions by weeks to months, and that trusts and lessors appear as owners by design rather than by concealment.

📰 Journalism and OSINT media

Fast, free and anonymous resolution suits verification work: identifying the type in a photograph, checking what a callsign in a document refers to, or establishing which carrier operates a given airframe. For anything published, the compiled record is a lead and the national registry is the source. Be particularly careful with the operator field, which can name a carrier that ended a lease years ago, and with the owner field, which names lessors and trusts that have no operational relationship with the aircraft. Say which database you used and on what date.

🌍 NGO, humanitarian and human rights

Supports documentation of arms logistics, sanctions circumvention and suspicious flight activity by turning observed addresses into named types and operators at a scale a small team can handle. The owner and operator split is genuinely useful in this work because leasing chains are a common mechanism in the cases these organisations document. The reporting obligation is to state the provenance honestly: compiled community data, of unknown currency, looked up on a stated date, corroborated where possible against registry records, with an explicit note that absence of a record proves nothing.

🎓 University and research

A convenient enrichment layer for research on ADS-B datasets and a useful object of study in itself, because the divergence between two community compilations of the same fleet is a measurable phenomenon that says something about how open datasets are maintained. For reproducible research, the lack of versioning and timestamps is a serious limitation: record resolution dates, and where results matter, resolve against a pinned local copy of an open aircraft compilation rather than a live third-party endpoint that may return something different next year.

Playbook: working hexdb.io end to end

A repeatable sequence from first pull to finished product. Each phase states what you are trying to establish, not merely what to click — the objective is a defensible chain of reasoning, not a completed checklist.

Phase 1 — Position it as the second resolver, not the first

Decide deliberately that this service exists in your architecture to disagree with another one. The value of a second compiled database is not that it is more accurate but that its disagreements localise your uncertainty. Configure it that way from the start rather than treating it as a fallback when the first one fails.

Phase 2 — Read a live response before writing a parser

Key names differ across the aircraft, route and airport endpoints, capitalisation is inconsistent, and missing data is represented differently in different places. Coding against remembered field names produces silent nulls that look like missing aircraft rather than like a bug in your code.

Phase 3 — Cache first, network second

Build the cache before you build anything else, with long retention for aircraft, effectively permanent retention for airports, and seasonal retention for routes. This is both the polite behaviour towards volunteer infrastructure and the only way the approach scales.

Phase 4 — Stamp and diff every resolution

Because the service exposes no record timestamp, your resolution date is the only temporal metadata that will ever exist. Store it, re-resolve on a schedule, and diff. The diff is where the intelligence is: a changed operator or owner is a transaction, and transactions are usually what the investigation is about.

Phase 5 — Keep owner and operator separate all the way through

Preserve both fields as distinct attributes from ingest to report. A leased airliner has a lessor as owner and a carrier as operator and both are correct. Collapsing them loses the leasing relationship, which in sanctions and export control work is frequently the relationship that matters.

Phase 6 — Treat blank fields as information

A missing operator on a commercial airframe is a signal, not just an absence. It often means the entry predates the aircraft's current arrangement or that the compilation never had a lease recorded. Classify blanks rather than filling them from the other resolver without recording that you did.

Phase 7 — Test routes against tracks, always

Take the airport pair from a route lookup and check it against the observed ADS-B track. Confirmation is a small gain. Contradiction is a finding, and in operational work the flights that did not go where the schedule said are precisely the ones worth examining.

Phase 8 — Age-check anything surprising

When a resolution produces an unexpected operator, an unusual owner or a type that does not match the track's performance, suspect a fossil record before you suspect a discovery. Check the alternate resolver and the registry before building anything on it, because old entries are this source's characteristic error.

Phase 9 — Escalate to the registry with a recorded date

For anything that will be named in a product or acted on, obtain the national registry record and log the registry, the query date and the retrieved values. Compiled data supports triage; registry data supports a claim. Keep the two clearly separated in the case file.

Phase 10 — Screen the resolved entities properly

Push both the operator and the registered owner through sanctions, PEP and corporate screening, not just one of them. Leasing structures are a standard route to obscuring control, and screening only the operator or only the owner misses half the exposure by design.

Phase 11 — Instrument the resolver itself

Track success rate, latency and disagreement rate as pipeline metrics. A free single-maintainer endpoint fails quietly, and without instrumentation the failure appears in your analysis as a period during which fewer aircraft happened to be identifiable, which is a conclusion you will draw wrongly.

Phase 12 — Have an exit

Decide in advance what you do if the service stops. The answer is usually a local mirror built from the open aircraft compilations plus a durable cache. Making that decision before you need it is the difference between a degraded pipeline and a broken one.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

What to pair it with

No single source carries a finding. These are the datasets that corroborate, extend or contradict this one — and a source that contradicts is worth more than one that agrees, because it is the only thing that will tell you when you are wrong.

Source	Relationship	What it adds
adsbdb	corroborates	The other free keyless resolver. Running both and comparing is the core quality control method for compiled aircraft identity.
OpenSky Network	prerequisite	Supplies the addresses and callsigns to resolve, and the tracks against which route hypotheses are tested.
Airframes.io	extends	Provides registrations and flight identifiers from datalink traffic, including for aircraft outside ADS-B coverage, which this service can then resolve to type and operator.
National civil aviation registries	supersedes	The authoritative record of registration and ownership. Where a registry answer is available, it replaces the compiled answer entirely.
OurAirports	corroborates	Open airport dataset for validating location indicators, coordinates and airport metadata returned by the airport endpoint.
NOAA Aviation Weather Center	extends	Once an airport is resolved, conditions and hazard products at that field explain a large share of the flight behaviour visible in the track.
OpenSanctions	extends	Screening for both the operator and the registered owner, which is where leasing structures either clear or become the finding.

Legal, ethical and operational constraints

Querying is unproblematic; what you do with the answers is where the constraints bite. Naming a company as an aircraft's operator or owner on the strength of an undated compiled record is a defamation exposure, and this source's fossil-record failure mode makes that exposure real rather than theoretical. In most data-protection regimes, registration data tied to an identifiable private individual is personal data, so retaining and analysing it needs a lawful basis, a purpose and a retention limit even though the lookups themselves are trivial. Where analysis supports sanctions, export control or law enforcement decisions, the evidential standard is set by that regime and compiled community data does not meet it – obtain the registry record. On licensing, the absence of published terms means you should not assume redistribution rights over the dataset, and bulk extraction to rebuild the database elsewhere should be discussed with the maintainer rather than assumed. Internal analytical use of individual lookups is plainly within the service's expected use.

Operational security

No authentication means no account trail, which is a real advantage when the identity of what you are researching is sensitive. The residual exposure is the same as any third-party lookup: the operator of the service sees your source address, your timing and the exact identifiers you request, and a concentrated burst of lookups against one unusual airframe is legible. Mitigate by resolving targets within a larger batch, by caching so that repeat interest never leaves your network, and by routing through infrastructure not attributable to your organisation where the matter warrants it. There is a subtler consideration too: because this endpoint is the default enrichment path for common receiver software, unusual query patterns stand out against a background of very regular hobbyist traffic. If you want to be invisible here, look like a receiver – low rate, cached, steady – rather than like an analytical pipeline.

Two rules that hold regardless of jurisdiction. Collection that is lawful is not automatically proportionate, and a dataset assembled for one purpose does not carry consent for another. Where the records concern identifiable people, the question is not only whether you may hold the data but whether holding it serves the purpose you are accountable for.

Is it earning its place?

Sources accumulate. Feeds get added during an incident and are never reviewed again, and a decade later the pipeline is carrying dead weight that nobody dares remove. These are the measures that show whether hexdb.io is contributing anything, and they are worth baselining now so the answer is available later.

Resolution success rate by aircraft class, tracked separately for airline, business, general and state aviation, because a blended figure hides the categories where the source is genuinely weak.
Disagreement rate with the alternate free resolver, broken down by field, which localises whether the divergence is about registration, type, operator or owner.
Proportion of resolved records where operator and registered owner differ, which is a direct measure of how much leasing structure your resolution is exposing rather than flattening.
Number of ownership or operator changes detected by scheduled re-resolution, which is the metric that shows whether you are using the source as a change detector rather than a static lookup.
Cache hit rate and outbound query volume, which together demonstrate that your use is sustainable against volunteer infrastructure.
Rate at which registry checks contradicted a compiled record, tracked over time as your empirical error rate for this source in your specific domain.
Median age of the cached resolution attached to findings in active cases, to catch long-running investigations quietly reasoning from stale identity data.

Beware of volume. Indicator counts rise easily and say almost nothing. Unique contribution — findings this source produced that no other source in your stack would have — is the measure that matters, and it is usually far lower than anyone expects.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Two resolvers, always. The single most valuable property of this service is that it is not the other one; its disagreements tell you where to spend registry effort, and running it alone throws that away.
Owner and operator are different questions with different answers, and a source that returns both is telling you about a leasing relationship. Preserve the distinction to the end of the workflow rather than picking whichever field is populated.
Assume every record could be a fossil. The compilation tradition behind this service accumulates entries rather than retiring them, so an unexpected result should raise suspicion of age before it raises excitement about a discovery.
Free-text type strings are not a controlled vocabulary. Group and count on the ICAO type designator; using the long type string for aggregation silently splits identical aircraft into several categories.
The flag code is for drawing pictures. It exists so that mapping software can pick a livery, and treating it as an operator identifier introduces errors that are extremely hard to trace once they are downstream.
Blank is data. A missing operator on a commercial aircraft usually means the compilation never recorded the current arrangement, and silently backfilling it from another source without recording that you did makes your two-resolver check meaningless.
Behave like a receiver, not a scraper. This endpoint carries continuous load from a large hobbyist installed base and has no funding behind it; a well-cached, low-rate integration is both the ethical and the durable choice.
Instrument the enrichment, because a quiet resolver failure looks in your data like a period when fewer aircraft were identifiable, and that is a conclusion an analyst will reach and act on if nothing tells them otherwise.
Never let a compiled operator or owner string be the last word before publication. The rule is not about this service specifically; it is about the fact that no undated compilation supports a named allegation.

Questions analysts actually ask

How is this different from adsbdb?

Different maintainer, overlapping but not identical upstream data, flatter responses, and a separate operator field alongside registered owner. The practical answer is to use both: agreement between two independently maintained compilations is cheap confidence, and disagreement tells you exactly which records need a registry check.

Why does it name a leasing company as the owner?

Because that is who holds the registration. A large share of the world airliner fleet is owned by lessors and operated by carriers, and business aircraft are frequently registered to trusts or banks. This is normal commercial structure, not concealment, and the operator field is where you look for who actually flies it.

How old can a record be?

There is no way to tell from the response, and in practice entries can be many years old. This is the source's most important limitation. Manage it with your own resolution timestamps and a re-resolution schedule, and be suspicious of any surprising result before treating it as a discovery.

Can I bulk-resolve a large fleet through this?

You should not. It is free single-maintainer infrastructure already carrying continuous load from thousands of receivers. For volume work, build a local mirror from the open aircraft compilations, which is more sustainable, faster for you, and gives you a pinned snapshot you can cite.

Why did my route lookup return nothing?

Most likely because the callsign is not a scheduled service. Charters, ferry flights, positioning legs, cargo tramp operations, business and government aviation have no compiled route. It can also mean the callsign format was wrong; route endpoints expect the ICAO form, not the IATA form.

Is an empty aircraft response evidence that the aircraft does not exist?

No, and treating it that way is a real error. An empty response conflates a privacy address, a genuinely uncompiled airframe, a malformed identifier and a service problem. Classify which one it is before drawing any inference, because a privacy allocation is itself a significant finding.

Can I redistribute the data?

Do not assume so. There is no prominent licence, and absence of stated terms is not a grant. The upstream compilations have varying terms of their own. Individual internal lookups are clearly within expected use; bulk extraction and republication are not, and should be discussed with the maintainer or avoided.

What should I do when the two free resolvers disagree?

Treat it as the useful outcome rather than a nuisance. Disagreement usually indicates a recent re-registration, a lease change or a stale entry in one of the compilations – all of which are informative. Go to the national registry, record the date, and note in the case which compilation was wrong and how.

How do I stop a resolver outage corrupting my analysis?

Instrument it. Track resolution success rate as a pipeline metric with an alert threshold, and make unresolved aircraft an explicitly flagged state rather than an absence. Otherwise an outage appears in your data as a genuine drop in identifiable traffic, which is exactly the kind of artefact that produces a confident wrong conclusion.

Standards, formats and interoperability

What this source speaks natively, and what it has to be translated into before a partner can consume it. Work that arrives in a recognised format is easier to defend, easier to hand over and easier to automate against:

ICAO 24-bit aircraft addressing under Annex 10, allocated in national blocks, is what makes the Mode S hex a meaningful key and what makes re-registration break the mapping.
ICAO aircraft type designators provide the controlled vocabulary for joining fleet data, in contrast to the free-text type string returned alongside them.
ICAO four-letter location indicators identify airports in route and airport responses, and are the correct join key to airport reference datasets.
Mode S is the underlying transponder protocol; an aircraft can be Mode S equipped without transmitting ADS-B position, which is why address resolution and positional tracking are separate problems.
National civil aviation registries are the authoritative upstream for registration and ownership, and every compiled aircraft database in this ecosystem is downstream of them with an unstated lag.
Open airport datasets supply the coordinates and codes behind the airport endpoint and carry their own coverage and currency characteristics.
The platform exports resolved aircraft, operator, owner and airport entities in STIX 2.1, MISP, CSV, JSON and JSONL for onward analysis and sharing.

References

Primary documentation and authoritative references for this source. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

hexdb.io — hexdb.io. The service itself, with the current description of the aircraft, route and airport endpoints. Read a live response from each before writing a parser.
adsbdb — adsbdb. The alternate free resolver, and the one to run alongside this for comparative resolution.
adsbdb source code — mrjackwills. Open implementation of an equivalent service, useful for understanding how these resolvers are built and what self-hosting would involve.
readsb — wiedehopf. The receiver decoder at the centre of the community stack that calls services like this, and the context for why the response format looks the way it does.
Mictronics — Mictronics. Community aircraft database work underlying much of this ecosystem, and the best available background on how these compilations are assembled and corrected.
OurAirports — OurAirports. Open airport reference data for validating and extending the airport records returned here.
International Civil Aviation Organization — ICAO. Standards authority for aircraft addressing, type designators and location indicators used across all three endpoints.
Federal Aviation Administration — FAA. Largest civil registry operator and the regulator whose trust-ownership arrangements explain much of what appears in the registered owner field.
OpenSky Network — OpenSky Network Association. The observation source that generates the identifiers this service resolves, and the track data against which route hypotheses are tested.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this source: it runs this alongside a second resolver on every address, records the disagreements as data quality flags, keeps operator and registered owner as separate claims, and escalates anything consequential to a dated registry check.. Browse the full source catalogue, or follow any tag above into the rest of the library.