RDAP vs WHOIS: What Developers Need to Know in 2026

If you've ever parsed WHOIS output, you know the pain. Every registrar formats it differently, there's no standard encoding, and you're left writing fragile regex to extract registrant names and expiration dates.

RDAP fixes all of that. It's the official replacement for WHOIS, defined in RFCs 7480–7484, and already required by ICANN for all gTLD registries. Here's what you need to know.

What is RDAP?

RDAP (Registration Data Access Protocol) is an HTTP-based protocol that returns structured JSON for domain, IP, and ASN lookups. It was designed by the IETF as the successor to WHOIS (port 43), which has been the standard since 1982.

Where WHOIS gives you unstructured plain text that varies by registrar, RDAP gives you a predictable JSON response with well-defined fields.

RDAP vs WHOIS: side by side

Feature	WHOIS	RDAP
Protocol	TCP port 43, plain text	HTTPS, JSON responses
Format	Unstructured, varies by registrar	Standardized JSON (RFC 9083)
Encoding	ASCII (mostly)	UTF-8 / Unicode
Authentication	None	HTTP-based (optional)
Access control	IP-based rate limits	Differentiated access per RFC 7481
Internationalization	Poor — IDN support is inconsistent	Native — Unicode domain names work
Discovery	Hardcoded server lists	IANA bootstrap registries (RFC 9224)
Referrals	Text-based, unreliable	JSON links to authoritative server

Why WHOIS is going away

ICANN has required all gTLD registries and registrars to support RDAP since 2019. While WHOIS port 43 still works for most TLDs today, it's officially deprecated:

• ICANN gTLD policy mandates RDAP support for all accredited registrars
• GDPR accelerated the transition — RDAP's access control model handles data redaction cleanly, while WHOIS has no standard way to restrict fields
• ccTLDs are following — many country-code TLDs (.uk, .au, .de) have added RDAP endpoints
• New TLDs launch with RDAP-only — some don't even offer WHOIS

The trend is clear: WHOIS will eventually stop responding, and your code needs to be ready.

How RDAP works

1. Bootstrap discovery

Unlike WHOIS, where you need a hardcoded list of servers, RDAP uses IANA bootstrap registries to discover which server handles a given TLD. The bootstrap file at https://data.iana.org/rdap/dns.json maps each TLD to its RDAP base URL.

2. HTTP query

Once you know the base URL, it's a simple GET request:

curl https://rdap.verisign.com/com/v1/domain/google.com

3. JSON response

The response follows RFC 9083 — standardized fields for domain name, status, events (registration, expiration), entities (registrar, registrant), and nameservers. No parsing required.

The catch: raw RDAP is still messy

While RDAP is a massive improvement over WHOIS, querying servers directly comes with its own challenges:

• Response formats vary — registries include different optional fields, nest data at different depths, and use inconsistent key names for the same concepts
• Contact data is buried — entities use vcardArray (RFC 6350), a deeply nested structure that's tedious to extract names and emails from
• Thin vs. thick registries — .com and .net use thin registries that only store basic data. The registrar (GoDaddy, Cloudflare, etc.) holds contacts and additional details in a separate RDAP server
• Rate limiting — upstream RDAP servers enforce rate limits, and each has different thresholds

This is exactly why we built RDAP API. One REST call returns normalized JSON — flat, consistent fields across 1,200+ TLDs. No vcardArray parsing, no bootstrap discovery, no chasing registrar referrals.

Migrating from WHOIS to RDAP

If you're currently using WHOIS in your application, here's how to migrate:

Option 1: Query RDAP servers directly

Replace your WHOIS client with HTTP requests to RDAP endpoints. You'll need to:

1. Fetch the IANA bootstrap registry to find the right server
2. Make an HTTPS GET request to the RDAP endpoint
3. Parse the JSON response, handling vcardArray for contacts
4. Follow referral links for thin registries (if you need registrar data)
5. Handle rate limiting and timeouts

Option 2: Use RDAP API

Skip the complexity. A single API call with a Bearer token gives you normalized data:

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://rdapapi.io/api/v1/domain/google.com?follow=true

The ?follow=true parameter automatically follows registrar referrals for thin registries like .com, merging both responses into one result. Here's what you get back:

{
  "domain": "google.com",
  "status": ["client delete prohibited", "server transfer prohibited", "..."],
  "registrar": {
    "name": "MarkMonitor Inc.",
    "iana_id": "292",
    "abuse_email": "[email protected]",
    "url": "http://www.markmonitor.com"
  },
  "dates": {
    "registered": "1997-09-15T04:00:00Z",
    "expires": "2028-09-14T04:00:00Z",
    "updated": "2019-09-09T15:39:04Z"
  },
  "nameservers": [
    "ns1.google.com",
    "ns2.google.com",
    "ns3.google.com",
    "ns4.google.com"
  ],
  "dnssec": false,
  "entities": {
    "registrant": {
      "organization": "Google LLC",
      "country_code": "US"
    }
  }
}

Flat, predictable, every field in the same place — no nested vcardArray, no inconsistent formatting across registries.

Key takeaways

1. RDAP is the standard now — WHOIS is deprecated and will eventually stop working
2. Structured JSON beats plain text — no more fragile regex parsing
3. Bootstrap discovery replaces hardcoded servers — IANA maintains the authoritative TLD-to-server mapping
4. Raw RDAP still has rough edges — vcardArray, thin registries, and inconsistent responses across registries
5. Normalization is the real value — whether you build it yourself or use an API, you want consistent output