RDAP vs WHOIS: how to reliably check a domain's expiry in 2026

If you've ever tried to read a domain's expiration date programmatically, you know the pain: WHOIS hands you a blob of free text that every registry formats differently. RDAP fixes that — it's the IANA-standardized, JSON-based protocol that replaced WHOIS, and it gives you a precise, machine-readable expiry you can trust. Here's the difference, and how to query it yourself.

WHOIS: free text you have to scrape

WHOIS predates the modern web. It's a plain-text protocol (originally over port 43) with no agreed schema. Ask two registries for the same field and you might get back any of these:

Registry Expiry Date: 2026-09-14T04:00:00Z
Expiration Date: 14-sep-2026
expire:           2026.09.14
paid-till:        2026-09-14T03:59:59Z

Same fact, four labels and three date formats. To read it reliably you end up maintaining a pile of per-registry regexes — and they break the moment a registry tweaks its output. On top of that, modern WHOIS is heavily rate-limited and redacted (post-GDPR most contact fields are gone), and many registrars actively discourage automated scraping. It was never designed to be a structured API, so treating it like one is fragile by nature.

RDAP: structured JSON, by standard

RDAP — the Registration Data Access Protocol — is the IETF/IANA-standardized successor (RFCs 7480–7484). ICANN has required gTLD registries and registrars to run RDAP since 2019. It speaks plain HTTPS and returns JSON. A domain query looks like this:

GET https://rdap.verisign.com/com/v1/domain/example.com
Accept: application/rdap+json

and the expiry comes back as a typed entry in the events array — no label-guessing, no date-format roulette:

"events": [
  { "eventAction": "registration",  "eventDate": "1995-08-14T04:00:00Z" },
  { "eventAction": "expiration",    "eventDate": "2026-08-13T04:00:00Z" },
  { "eventAction": "last changed",  "eventDate": "2025-07-09T01:43:11Z" }
]

You filter for eventAction === "expiration" and read a single ISO 8601 timestamp. That's the whole job. It's the same answer every registry gives, in the same shape, every time.

Finding the right server: the bootstrap registry

There's no single global RDAP endpoint — each TLD's registry runs its own. IANA publishes the authoritative map at https://data.iana.org/rdap/dns.json, the RDAP bootstrap file. You look up the domain's TLD, get its base URL, and append /domain/<name>. That's exactly how a correct client resolves where to ask — and it's how we resolve it too.

The honest edges

• ccTLD gaps. ICANN's RDAP mandate covers gTLDs, not country-code TLDs. Several popular ones — .io, .co — aren't in the bootstrap registry yet, so RDAP can't read them. We're honest about that instead of silently scraping a flaky fallback.
• Rate limits. RDAP servers throttle too, so a sane client backs off and caches. For one-off lookups it's a non-issue.
• Expiry ≠ deletion. The expiration date is when the registration term ends; there's usually a grace/redemption window after it. But it's the date to act before, which is why we alert ahead of it.

Why this is the foundation of a trustworthy check

When we say Domain Watchdog reads “the official registry record,” this is literally what we mean: a daily RDAP query against the registry's own server, reading the structured expiration event — no HTML scraping, no third-party data broker, no guesswork. If you're the technical decision-maker evaluating whether to trust a tool with your client list, that's the part that should matter: the data source is the authoritative one, read the standardized way.

Want to see it in action? check any domain's expiry, free — the result you get is the exact RDAP expiration event, with days remaining. And if the bigger fear is a client site silently going dark, read the silent domain lapse.