WHOIS vs RDAP — a detailed comparison

Key facts: WHOIS vs RDAP

• WHOIS: from RFC 812 (1982), current RFC 3912 (2004), over TCP port 43, plain text — the format varies by registry.
• RDAP: defined in RFC 7480–7484 (2015); query and response formats updated by RFC 9082/9083 (2021), server discovery specified by RFC 9224 (2022), using HTTPS and JSON.
• Since 2019, ICANN mandates RDAP for all gTLDs, and most major ccTLDs (.tw, .jp, .uk, .de) support it too.
• ICANN's legacy WHOIS/port-43 contractual obligation for gTLDs was formally sunset on January 28, 2025, making RDAP the only mandatory protocol for gTLD registration data.
• This site prefers RDAP and only falls back to legacy port-43 WHOIS when a registry does not provide it.

WHOIS vs RDAP at a glance

Why RDAP? Isn't WHOIS enough?

Legacy WHOIS has been in use since 1982 (RFC 3912 is the current version) and has several limitations that are hard to ignore on the modern internet:

• The plain-text format has no standard: every registry/registrar emits a different layout, so software must write parsing rules for each one.
• There are no standard error codes: when data is missing or you are rate-limited, the connection often just drops, making the cause hard to diagnose.
• Internationalization support is weak: IDNs and non-ASCII characters are handled inconsistently.
• There is no native encryption: port 43 is cleartext, which fails audit and compliance requirements.

IETF therefore drove the successor standard RDAP, published in 2015 as RFC 7480–7484, with ICANN requiring gTLD registrars to deploy it; the query and response formats were later updated by RFC 9082 and RFC 9083 (2021).

How is port 43 different from HTTPS?

WHOIS uses TCP port 43 with no encryption — a plain-text request/response sent in one shot before disconnecting. RDAP, by contrast, is built on the modern HTTP stack:

• Transport: RDAP runs over HTTPS (TLS), compatible with browser, CDN and API-gateway workflows.
• Status codes: it supports standard HTTP status codes (200/404/429/500) and content negotiation.
• Auditable: for enterprise environments that need compliance and auditing, RDAP is an auditable, traceable option.

Server discovery is standardized too: an RDAP client can follow the IANA bootstrap registry defined in RFC 9224 to find the correct RDAP endpoint for a TLD automatically, without hard-coding each server's address.

Why is RDAP's JSON easier to parse than plain text?

WHOIS returns a human-readable plain-text block that every registry lays out differently (.com and .tw look nothing alike), so parsing requires a separate rule set per TLD. RDAP's JSON, by contrast, is consistent across TLDs:

• The object structure follows RFC 9083: fields such as entities, events, nameservers and status are standardized.
• The media type is application/rdap+json, which can be fed directly to code or front-end components without writing a parser for each case.
• Contacts are expressed as jCard (RFC 7095, based on vCard RFC 6350), so name/organization/address parse consistently.

Current compatibility: who already serves RDAP?

RDAP coverage is already very high, but not yet universal:

• Every ICANN gTLD (.com, .net, .org, .io, etc.) is required to have its registrars and registry provide an RDAP endpoint.
• Most major ccTLDs (.tw, .jp, .uk, .de, etc.) also support RDAP.
• A few smaller ccTLDs still only maintain legacy WHOIS, in which case a fallback to port-43 lookup is required.

ICANN's legacy WHOIS/port-43 contractual obligation for gTLDs was formally sunset on January 28, 2025 — RDAP is now the only mandatory protocol for gTLD registration data, while each ccTLD registry sets its own transition timeline.

How this site integrates both

The whois.net.tw backend combines the two protocols into a single lookup, so you never have to choose:

• It resolves the TLD's RDAP endpoint from the IANA-published bootstrap registry (RFC 9224) and tries RDAP first.
• If the TLD has no RDAP or returns an error, it automatically falls back to port-43 WHOIS and displays the normalized plain-text result.
• The result page clearly labels whether the data source was RDAP or WHOIS, so you can trace the protocol behind every lookup.

How to query domain information with WHOIS and RDAP

1. 1

   Enter a domain and run a lookup

   Type any domain name into the homepage search box. The tool automatically prefers RDAP; if the TLD does not yet support RDAP it falls back to port-43 WHOIS.

2. 2

   Check the data-source label

   The result page shows whether data came from RDAP (HTTPS + structured JSON) or WHOIS (port-43 plain text), making it easy to observe the protocol difference first-hand.

3. 3

   Compare the field structure

   RDAP uses consistent field names (registrar, expirationDate, etc.) and jCard contact objects; WHOIS field formats vary by registry — a direct side-by-side comparison of both protocols.

See the difference with a real domain

Back on the home page, type a domain — the result page's Data Source field tells you whether this lookup came back via RDAP or WHOIS.

References

• RFC 3912 — WHOIS Protocol Specification — Current WHOIS protocol (2004)
• RFC 7480 — RDAP over HTTP — RDAP transport layer
• RFC 9082 — RDAP Query Format — Replaces RFC 7482
• RFC 9083 — RDAP JSON Responses — Replaces RFC 7483
• RFC 9224 — Finding the Authoritative RDAP Service — Replaces RFC 7484, bootstrap
• RFC 7095 — jCard: vCard in JSON — RDAP contact format
• IANA — RDAP Bootstrap Service Registry — RDAP endpoints for each TLD
• ICANN — Registration Data / RDAP — gTLD RDAP policy and status