WHOIS vs RDAP: what changed and why it matters

WHOIS and RDAP are two different protocols for looking up who registered a domain. WHOIS returns unstructured plain text in a format that varies by registry. RDAP returns structured JSON over HTTPS with a documented schema. Since 28 January 2025, RDAP is the only protocol ICANN requires generic top-level domain registries and registrars to run for registration data. WHOIS access past that date is optional legacy behavior, not a guarantee.

That distinction rarely shows up in the tools people actually use. A domain lookup form asks for a name and returns a record; it does not announce which protocol answered. Most modern lookup tools, including WebPixie’s own domain lookup, try RDAP first and fall back to WHOIS automatically per TLD, because not every registry has finished the switch. The result looks the same either way. What is behind it does not.

What actually differs under the hood

The two protocols solve the same problem with almost nothing in common at the transport level.

	WHOIS	RDAP
Transport	Plain text over TCP port 43	HTTPS REST, JSON responses
Response format	Registry-specific, no shared schema	Standard schema, RFC 9083
Query format	Free-text, no standard syntax	Standard URL query paths, RFC 9082
Access control	None built in, ad hoc rate limiting	Tiered response objects per requester type
Multi-registry lookups	Often two hops: registry WHOIS, then a referral to the registrar's own WHOIS server	Structured links in the response point to the authoritative source directly

The two-hop WHOIS pattern is the part people notice without knowing why: a .com lookup against Verisign’s registry server frequently returns only a pointer to the domain’s actual registrar, which you then have to query separately for the full record. RDAP folds that into one response with a link object instead of a second manual query.

Seeing the difference yourself

Both protocols are queryable directly, and the shape of the output makes the difference concrete rather than abstract. A raw WHOIS query over port 43 returns free text with no fixed structure:

whois example.com

The response is whatever fields that specific registry decided to print, in whatever order and labeling it chose. Two different TLDs can format the same fact, a registrar name, differently enough that a parser tuned for one will silently mis-read the other.

The equivalent RDAP query is an HTTPS request that returns JSON:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.'

The response carries named, typed fields (ldhName, events, entities, status) defined by RFC 9083, plus links entries that point directly to the authoritative registrar record instead of leaving you to guess where to look next. Every gTLD registry’s RDAP response uses the same field names for the same facts, which is the entire practical argument for the switch: one parser instead of one per registry.

Why RDAP exists: WHOIS never had a schema

WHOIS predates any of this by decades and was never standardized beyond the wire protocol itself (RFC 3912, 2004). Every registry formatted its response text differently, which meant anyone parsing WHOIS programmatically was maintaining a pile of per-registry regexes that broke whenever a registry changed its output formatting. Redaction rules introduced after GDPR made this worse: registries needed a way to return different fields to different requester types, and plain text had no mechanism for that.

The IETF formalized the replacement as RFC 9082 (query format) and RFC 9083 (response format), both published as Internet Standard 95 in June 2021. RDAP is not a WHOIS wrapper. It is a REST API with a defined JSON schema, built specifically to carry differentiated access control that WHOIS text never could.

The ICANN timeline, verified

The move from optional to mandatory took six years, in four dated steps:

26 August 2019: ICANN’s deadline for all gTLD registries and registrars to stand up an RDAP service alongside their existing WHOIS service, per a six-month implementation window announced by ICANN.
June 2021: RFC 9082 and RFC 9083 published as STD 95, giving RDAP a formal, versioned specification instead of an ICANN-only contractual requirement.
30 April 2023: ICANN’s board approved global contract amendments adding RDAP-specific obligations to the base gTLD Registry Agreement and Registrar Accreditation Agreement, replacing the interim policy language.
28 January 2025: RDAP became the sole ICANN-mandated source for gTLD registration data. WHOIS support for gTLDs is no longer a contractual requirement from this date forward.

⚠️

This timeline covers generic top-level domains (.com, .org, new gTLDs) under ICANN contract. Country-code TLDs are run by their own national registries and are not bound by ICANN’s RDAP requirement. Some ccTLDs offer RDAP today, some do not, and a handful never ran a public WHOIS service to begin with. Check the specific registry before assuming RDAP coverage for a non-gTLD domain.

If you are building on top of this

Scraping WHOIS text was already a maintenance burden before the ICANN deadline; treating it as the primary integration path going forward is a bet against a protocol that is being actively wound down for the domains it still covers. RDAP’s JSON schema is stable across registries in a way WHOIS output never was, which is the actual argument for switching, not just that ICANN says so.

RDAP is not friction-free. Its differentiated access control means the fields you get back can depend on who is asking, which makes a public RDAP response less complete than what a logged-in registrar dashboard shows for the same domain. It is more structured than WHOIS. It is not more open.

That gap matters most for anyone polling records on a schedule rather than looking one up by hand: a script built against the public RDAP response should expect fewer fields than a manual WHOIS lookup ever showed, not treat the shrinkage as a bug.