What the decoder does
It recognises field names. A whois record is free-form text with no schema, so every tool that reads one carries a table of the labels registries actually use, and this is that table made visible. An RDAP response is JSON with defined member names, so the same field can be read out of either format and explained the same way.
Lines it does not recognise are listed rather than dropped. That matters for country-code registries, which each invent their own labels, and it means the decoder never quietly discards something it did not understand. The legal boilerplate every registry appends is ignored, which is why a whole record can be pasted in without trimming it first.
The three fields worth reading first
Creation date, last-changed date and status. Read together they reconstruct a registration's history: an old creation date with a recent change means an established name that was just touched, and a recent creation date on a name with years of external history means the old registration lapsed and a new one was created. The status codes then locate the name in the domain lifecycle.
The full field reference is on the whois record page, and the structured equivalent is covered under reading an RDAP response. For the nameserver list, and particularly for what an empty one means, see nameservers and delegation.
Where the labels come from, and why they vary
Registries are not obliged to agree on wording. A generic top-level domain registry has a
contractual output format and therefore looks consistent, which is why records for those
extensions parse cleanly. Country-code registries answer to their own national policy and
use their own vocabulary: the same fact appears as changed, as
last-modified, as Updated Date, or as a line with no label at all.
That is the whole reason the decoder keeps a table rather than a rule. Every tool that has ever read a whois record carries the same table, usually invisibly, and the invisible version is where wrong answers come from: a label it does not know gets dropped, and a field that was present is reported absent. Listing the unrecognised lines is the honest alternative, and it also makes the gaps in the table visible so they can be filled.
Where a registry publishes both, prefer RDAP. Not because it holds more, but because nothing has to be guessed: the members are named in a specification, so a client either recognises a member or the member is genuinely not there. That difference is the entire argument for the newer protocol, and it is set out on reading an RDAP response.
Three different reasons a field looks empty
An empty field is the most misread thing in a registration record, because three unrelated situations produce the same blank space and only one of them means the data does not exist.
The first is a thin registry. Some registries store only the sponsoring
registrar, the domain status and the dates, and leave every contact detail with the registrar
that sold the name. .com and .net are the long-standing examples. A
thin record is short by design and carries a Registrar WHOIS Server line, which
is the pointer to where the rest is held: the record is complete, it is just not the whole
registration. A thick registry answers with both halves at once, which is why the same query
returns four lines for one extension and forty for another.
The second is redaction. Since the contact fields in generic top-level
records were withheld for data-protection reasons, a registrant name is commonly returned as
REDACTED FOR PRIVACY and the mail address as a forwarding or role-based one. That
is a populated field whose value is withheld, not a missing one — the registrar still holds
the detail, and the presence of the placeholder is itself the evidence. Reading it as an
absent record is the mistake, and it is the reason a record that looks anonymous is not the
same as a registration nobody stands behind.
The third is a label this decoder does not recognise, and it is the only one of the three that is a shortcoming rather than a fact about the registration. Those lines are listed rather than discarded, under the unrecognised heading, so the gap is visible in the output instead of being reported as an absence.
The same three cases apply to an RDAP response, where they are easier to tell apart: a
withheld value carries a redacted member naming what was removed, and a member
that is genuinely not there is genuinely not there.
Privacy
There is no server side to this tool. The parsing runs in the page, the text never leaves the browser, and your machine keeps nothing afterwards. That is not a policy statement so much as a description of the implementation: the decoder cannot transmit what you paste, because it contains no code that transmits anything.