RDAP vs WHOIS: what is the difference?

The short answer

WHOIS is a simple text protocol: you open a connection to a server on port 43, send a domain name, and read back whatever text comes out. Every registry formats that text differently. RDAP (the Registration Data Access Protocol) answers the same questions through ordinary HTTPS requests and returns JSON with defined fields, proper status codes and a standard way to say that something was redacted.

For people, the difference shows up as cleaner, more consistent results. For software, it is the difference between parsing free-form text with fragile regular expressions and reading a documented data structure. Try both views with the WHOIS lookup and the RDAP lookup.

A short history

How WHOIS works, and where it falls short

A WHOIS client connects to a server, sends the name followed by a line break, and the server replies with text and closes the connection. You can do it by hand:

# Raw WHOIS exchange
printf 'example.com\r\n' | nc whois.verisign-grs.com 43

# Or with the standard client
whois example.com

This simplicity is why WHOIS lasted forty years, and also why it needed replacing:

• No standard format. Field names, order, date formats and even the text for “not found” differ between registries, so every parser is a pile of special cases.
• No structured errors. A rate limit, a missing domain and a server fault all look like text. There is nothing like an HTTP status code.
• No discovery. The protocol does not say which server to ask. Clients ship tables of servers, or follow referrals in the text.
• No encryption or authentication. Queries and answers travel in clear text, and every client gets the same data.
• Poor internationalisation. Character sets are not specified, so non-ASCII names and addresses are often mangled.
• No redaction vocabulary. A blank field might mean redacted, unknown or not applicable.

How RDAP works

RDAP keeps the idea of public, queryable registration data but runs on the web. A client sends an HTTPS GET request such as https://rdap.example-registry.net/domain/example.com, and the server replies with JSON and a normal HTTP status code. 200 means found, 404 means no such object, 429 means slow down. The structure of the reply is defined in RFC 9083.

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2001-03-01T00:00:00Z" },
    { "eventAction": "expiration", "eventDate": "2027-03-01T00:00:00Z" }
  ],
  "nameservers": [{ "ldhName": "ns1.example-dns.net" }],
  "entities": [{ "roles": ["registrar"], "vcardArray": ["vcard", [["fn", {}, "text", "Example Registrar"]]] }],
  "links": [{ "rel": "self", "href": "https://rdap.example-registry.net/domain/example.com" }]
}

That example is abridged and illustrative. Real responses add notices, contact details, DNSSEC data and a list of the RDAP extensions the server supports.

Bootstrap: finding the right server

IANA publishes a bootstrap registry (RFC 9224) listing the RDAP base URL for each top-level domain, IP block and AS number range. A client looks up the extension, builds the request URL and sends it. For domains in a thin registry such as .com, the registry's answer includes a related link to the registrar's own RDAP record, where fuller contact data may live. LookupOwl follows that link once and merges the two views.

Redaction and access control

Because RDAP uses HTTP, a server can require authentication and return different data to different users. It can also say that fields have been hidden and why. RFC 9537 defines a redacted member listing each removed field and the method used. An anonymous visitor therefore sees a labelled blank instead of an unexplained gap.

Side by side

Privacy, GDPR and what you can still see

Moving to RDAP did not by itself hide personal data. The hiding came from privacy law and from ICANN's response to it in 2018. For most registrations today, both WHOIS and RDAP show the registrar, the domain's dates, its status flags and nameservers, an abuse contact and, for the owner, a redaction notice. Some registrants who are companies, or who opt in, still publish their details.

If you need to reach the owner, use the registrar's abuse contact for abuse and the web form or relay email that many registrars provide for other messages. Do not expect a name and home address. See the WHOIS lookup for what each domain publishes.

What this means in practice

• Use RDAP when it exists. It is consistent, machine-friendly and where registries are putting their effort. This is what LookupOwl asks first.
• Keep WHOIS as a fallback. Many country-code registries have no RDAP service, and a few block automated RDAP queries. LookupOwl falls back to the registry's port-43 server for those.
• Do not write new parsers for WHOIS text. If you build software, use RDAP libraries or an API that already normalises the data, such as the LookupOwl REST API or MCP server.
• Expect differences between registries. Even in RDAP, servers vary in which events and contacts they include. Some omit creation dates (Germany's .de publishes none), and some return little to anonymous users.
• Treat the text as untrusted. Notices and remarks are free text from third parties. Software, and especially AI agents, should treat them as data and not as instructions.

Related tools: domain age, domain expiry, availability, EPP status codes and IP WHOIS (RDAP also covers IP addresses and AS numbers).