WHOIS privacy across TLDs: Why the toggle doesn’t work the same everywhere and how to handle it in code

Most developers building domain registration flows treat WHOIS privacy as a binary toggle: on or off, enabled or disabled. Privacy support is determined entirely by registry policy, not registrar capability. For a substantial slice of ccTLDs, no privacy proxy is legally permitted regardless of what your UI offers or what your API call sends.

name.com manages over 2.4 million domains across 600+ TLDs, and our Domain Safe privacy product explicitly documents which TLDs don't support WHOIS privacy because many registries don't allow it. If your registration flow handles even a handful of ccTLDs, you're already operating across at least two of the three distinct privacy regimes that coexist right now.

Those three regimes are the core of what follows, along with why they exist and how to check for privacy support programmatically before your UI makes a promise the registry won't honor.

1. The governance split that causes everything else

The ICANN/ccTLD authority divide is the root cause of every inconsistent privacy behavior you'll encounter in multi-TLD registration flows.

ICANN governs generic top-level domains such as .com, .net, .org, and the full catalog of new gTLDs like .app and .dev. ccTLD registries operate under a different authority structure. Nominet runs .uk. CIRA runs .ca. DENIC runs .de. GoDaddy Registry runs .us. The registries follow national law in operating ccTLDs, and national law determines whether privacy proxies are legally permissible.

That authority split is why a privacy flag that works cleanly for .com doesn’t have the same application to .ca. The registrar isn't failing; the registry is legally prohibited from honoring the request. In API terms, that prohibition surfaces differently depending on the operation. A registration request sent with privacyEnabled: true returns HTTP 200 but overrides the flag to false, and no error is raised. Calling :enableWhoisPrivacy on the domain produces the same result: HTTP 200, privacyEnabled: false. A PATCH call to /core/v1/domains/{domainname} attempting to enable privacy returns HTTP 409. And calling :purchasePrivacy directly returns HTTP 422 — "TLD does not support WhoIs Privacy." Four different surfaces, four different responses, none of them consistent. All preventable with a single pre-flight check.

2. What RDAP actually changes

RDAP replaces WHOIS's flat text output with structured JSON, but it doesn't unify privacy policy across TLDs.

RDAP (Registration Data Access Protocol) replaces WHOIS's flat, unstructured text output with structured JSON over HTTPS, as specified in RFC 9083. The tiered access model means the same endpoint returns different data depending on who's asking. A general public request gets redacted contact information, while an authenticated request from an accredited party gets full registrant details. That's a meaningful improvement for developers consuming registration data at scale.

ccTLD registries can voluntarily adopt RDAP, and many have. You can verify this against the IANA RDAP Bootstrap Registry, which is the authoritative source for which TLDs have registered RDAP endpoints and where to query them. It's useful for developers querying registration data across registrars, and a good spot-check companion to ICANN's own lookup tool.

Adopting the RDAP protocol doesn't mean adopting ICANN's data policy. A ccTLD that voluntarily runs an RDAP service still discloses data according to its own national rules.

The practical implication: querying RDAP for a .us domain returns unredacted registrant data (name, address, email, phone number) because US law requires it. Querying RDAP for a .fr individual registrant returns redacted data because AFNIC's policy, shaped by GDPR, restricts it by default. The protocol changed; the policy fragmentation didn't.

3. A working map of the three WHOIS privacy regimes

These three regimes cover the full range of privacy behavior you'll encounter across TLDs.

Regime 1: Privacy proxy supported (most gTLDs: .com, .net, .org, and new gTLDs)

Registrar-level proxy replaces registrant data in WHOIS and RDAP records. The proxy service becomes the listed registrant, and communications forward to the actual owner. Under RDAP, GDPR additionally drives auto-redaction for EU registrants even without an explicit proxy enabled. This is the regime most developers code to, and incorrectly treat as universal when they begin expanding to ccTLDs.

Regime 2: Registry-level auto-redaction, no proxy needed or permitted

DENIC (.de), the Swiss and Liechtenstein registries (.ch and .li, since January 1, 2021), and AFNIC (.fr) (for individual registrants only, not legal entities) restrict public access to personal data at the registry level. The registry handles redaction automatically. Enabling a privacy proxy here is redundant, and for most of these TLDs, a prohibited service. A user registering a .de domain gets privacy protection by default, with no purchase required.

For developers, this regime requires a different user message than Regime 3. Don't suppress the privacy toggle without explanation. Tell the user why it's absent, and that they're already covered. Silence looks like an oversight.

Regime 3: Mandatory public registrant data, privacy services blocked

.us, .ca, .uk (including .co.uk), .au, .in, .nl, and several others require accurate, publicly visible registrant contact information. National registry rules prohibit privacy proxies. No workaround at the registrar level can change this because it's a registry-level legal mandate. Domain Safe explicitly does not apply WHOIS privacy to these TLDs.

4. Checking WHOIS privacy support before the order

Check privacy support before you render a registration form, not after a failed order. The name.com API exposes exactly this:

GET /core/v1/domaininfo/requirementsV2/{tld}

This endpoint returns TLD registration requirements as JSON Schema Draft-07. Parse the response and inspect the supportsPrivacy flag. If it's false, suppress the privacy toggle before the user ever sees it and render the appropriate messaging for their regime.

A .ca check:

curl -u 'username:token' \
  https://api.name.com/core/v1/domaininfo/requirementsV2/ca

Representative response:

{
  "supportsPrivacy": false,
  "tld": "ca",
  ...
}

And the equivalent for .com:

curl -u 'username:token' \
  https://api.name.com/core/v1/domaininfo/requirementsV2/com

{
  "supportsPrivacy": true,
  "tld": "com",
  ...
}

That flag is your gate. Everything else in your privacy UX follows from it.

Skip the pre-flight check and send a privacy request on an unsupported TLD, and you'll hit one of three failure modes depending on the operation.

Failure Mode 1 — Silent override on registration

A registration POST with "privacyEnabled": true for .ca returns HTTP 200. No error is raised. But the response body includes "privacyEnabled": false as the flag was accepted and ignored. Your user believes privacy is active. It isn't. The same behavior occurs when calling :enableWhoisPrivacy directly on an existing .ca domain: HTTP 200, privacyEnabled: false.

Failure Mode 2 — 409 on privacy toggle

A PATCH update attempting to enable privacy on an existing .ca domain returns HTTP 409 with this exact message:

{"message":"WHOIS Privacy is not currently available for this domain, so its status cannot be toggled. You may need to purchase WHOIS Privacy to enable this feature for the domain."}

The message implies a purchase will resolve the issue. It won't.

Failure Mode 3 — 422 on privacy purchase

Following that suggestion and calling :purchasePrivacy on the .ca domain returns HTTP 422:

{"message":"TLD does not support WhoIs Privacy"}

Three interactions, three failure points, zero useful outcome. The requirementsV2 pre-flight check collapses all three into a single gate that prevents the user from reaching any of them.

If you're auto-generating registration forms from the schema (which the JSON Schema Draft-07 format makes straightforward), run the requirementsV2 response through a validator like ajv before rendering. The full schema includes required fields, allowed character sets, contact format constraints, and registrant type restrictions (individual versus organization) that vary by TLD. The privacy flag is one property in a richer per-TLD requirements object.

5. What to tell users when WHOIS privacy isn’t available

Hiding the privacy toggle without explanation, or showing it grayed out with no context, is the worst pattern you can follow. Users who registered a .com domain last month expect WHOIS privacy to work the same way everywhere. If you don't tell them otherwise, they'll assume their data is protected.

Ready-to-use copy for each of the three scenarios:

Mandatory public TLD (.ca, .us, .uk, .au, .in, .nl):

"Privacy protection is not available for [TLD] domains. The operating registry requires registrant contact information to be publicly visible. Your name, address, and email address will appear in WHOIS and RDAP records."

Registry-auto-redacted TLD (.de, .ch, .li, and .fr for individual registrants only):

"Your [TLD] registration is protected by the operating registry’s data policy, which restricts public access to personal data by default. No separate privacy purchase is needed."

Note the .fr edge case: AFNIC auto-redacts only for individual registrants. Legal entities registering a .fr domain fall into Regime 3, where their data is public. Your messaging logic needs to account for registrant type, not just TLD.

Supported TLD with privacy disabled by user choice (.com, .net, .org with privacy off):

"Your name, email, phone number, and mailing address will be publicly visible in WHOIS and RDAP records. Consider enabling privacy protection to keep this information private."

Don't hardcode TLD names into your UI copy. The supportsPrivacy flag is your source of truth for toggle eligibility, and the regime classification drives which message to render. TLD rules get updated, new ccTLDs adopt RDAP, and national privacy laws evolve. A dynamic check against the live endpoint is always preferable to a static list.

6. What proxy WHOIS privacy actually means in supported cases

For supported TLDs, Whois Privacy keeps your registrant's name, address, phone number, and email hidden from public WHOIS and RDAP records. The mechanism is registrant substitution as the proxy becomes the listed contact of record, not just a mask over the existing data. Developers with legal or compliance requirements should confirm the specifics in the applicable registrar-registrant agreement for their domain.

The proxy service entity becomes the listed registrant in WHOIS and RDAP. All domain-related communications route to the proxy, which forwards them to the actual owner. The real registrant's name, address, email, and phone number appear in no public record.

That distinction matters. Data masking techniques (replacing characters with redaction markers while leaving the record structure intact) can still expose metadata. Registrant substitution doesn't, because the proxy is the legal contact of record. The real owner's information exists only in the registrar's private database, where it's accessible to law enforcement and for legitimate abuse resolution but not to the general public.

7. Implement the WHOIS privacy gate

The implementation is one call and one conditional:

GET /core/v1/domaininfo/requirementsV2/{tld}

Parse the JSON Schema Draft-07 response. Read supportsPrivacy. If false, suppress the privacy toggle and render the appropriate regime-specific message from the templates in Section 5. If true, show the toggle with a standard public-exposure warning for users who choose to leave it off.

If you're not yet integrated with our API, run requirementsV2 as a pre-flight batch call across your entire supported TLD catalog. Use the results to build a local lookup table, cache it, and use it to gate your UI while you complete the full live integration. Replace the local table with live endpoint calls before you ship to production, because a stale static list will eventually reflect a registry rule that changed.

If you're already consuming the schema for form generation, use ajv to validate the full requirementsV2 response before you render. The schema encodes the complete set of per-TLD requirements, and privacy eligibility is one field in a much larger contract.

Three privacy regimes, one API endpoint, one flag. The governance complexity is real, but the implementation is straightforward once you've wired in the pre-flight check. Developers who skip this step end up with silent overrides on registration and privacy toggle calls, a 409 on PATCH updates that points toward a purchase that will immediately return a 422 code, and users who believe their data is protected when the registry has had it on public record the whole time.

Get your free API token and explore the name.com API docs at docs.name.com.