Minecraft MOTD and the Java status response explained

Direct answer: The multiplayer server list does not “log in.” It runs a short Server List Ping (SLP) status exchange over TCP and reads a JSON object that may include a message of the day (MOTD), version name, protocol number, player counts, an optional sample, an optional favicon, and flags such as enforcesSecureChat. That packet proves a status endpoint answered this handshake from this vantage. It does not prove join success, authentication health, or that displayed player counts are honest.

The modern (1.7+) status exchange

At a high level:

1. Client opens TCP to the resolved host:port.

2. Client sends a Handshake with next state = status, then a Status Request.

3. Server returns a Status Response whose payload is a length-prefixed JSON string.

4. Client may send a Ping with a payload; server replies with Pong and closes.

If the modern response is missing or malformed, Notchian clients may fall back to older legacy ping formats. A third-party checker may implement only the modern path.

Handshake protocol field and -1

In the handshake, the client includes a protocol version. When the client is only pinging to learn what the server speaks, the documented convention is to send -1. That sentinel is not “broken JSON”; it is an intentional “version unknown / discovery” value for the handshake.

Separately, some reverse proxies and multi-version frontends put version.protocol: -1 (or other non-marketing integers) in the response JSON while still returning a usable description. A checker that treats every negative protocol as malformed will under-report Online. Rejecting a clean status frame solely because the echoed protocol is -1 is a tooling choice, not proof the server is offline.

Status JSON fields (what they mean)

Illustrative shape from the protocol documentation (example values only):

{
  "version": {
    "name": "1.21.8",
    "protocol": 772
  },
  "players": {
    "max": 20,
    "online": 1,
    "sample": [
      { "name": "thinkofdeath", "id": "4566e69f-c907-48ee-8d71-d7ba5aa00d20" }
    ]
  },
  "description": { "text": "Hello, world!" },
  "favicon": "data:image/png;base64,<data>",
  "enforcesSecureChat": false
}

MOTD / description details

• Vanilla servers may embed legacy section-sign color codes inside text rather than full rich components.

• Third-party server software may return structured text components. Parsers should accept both a string and an object.

• MOTD text is untrusted display data. It must be escaped if rendered as HTML; never execute it as markup or script.

Favicon details

• Optional. When present, documentation expects a PNG, Base64-encoded, prefixed with data:image/png;base64,.

• Since 1.13, embedded newlines in that field are not supported the way older clients allowed.

• Notchian clients expect a 64×64 source image for reliable rendering.

Players object details

• Protocol / multiplayer-list tolerance: community protocol notes allow a status JSON shape where players is absent; the vanilla list UI may then show an unknown-style count rather than zeros.

• This checker’s accepted schema: the MinecraftStatus parser requires a players object with integer online and max. A response that omits players can be tolerated by a permissive client yet classified as malformed/Unknown here.

• online and max on vanilla software are bounded by signed 32-bit positive range behavior; exotic large values are not something tools should treat as sacred truth.

• Samples can be empty, omitted, or anonymized by server software or operator privacy settings (for example hiding the online-player sample). That control is not an individual player “disabling server listings” in the multiplayer browser.

Diagnostic flow

1. Confirm edition. This article is Java SLP. Bedrock uses a different unconnected-ping model—see Java vs Bedrock status checks.

2. Confirm the address path, including SRV if relevant, before blaming the MOTD parser.

3. Run a status check on the server checker or via the status API field guide.

4. Read the verdict first (online / offline / unknown), not the MOTD colors. See Online, Offline, and Unknown.

5. If Online: inspect version, MOTD, and counts as advertisements. Cross-check with whether clients can actually join.

6. If protocol looks odd (including -1): treat it as a version-advertisement quirk until you have a transport failure. Do not equate “unexpected protocol integer” with Offline.

7. If Unknown: look for timeout, reset, malformed framing, DNS failure, or policy blocks—not “the MOTD was ugly.” Also consider schema rejection (for example missing required players under this checker) as a tooling boundary, not automatically “the server is down.”

8. If Offline: that should mean the admitted target refused the TCP status connection, not merely that the MOTD failed to parse.

Evidence limits

• Status is anonymous and unauthenticated. It is not a login, join, or Realms check.

• Player counts and samples are server-controlled. They can be spoofed, rounded, or hidden by operator/software settings.

• Protocol documentation tolerance and this product’s accepted JSON schema are different contracts. Do not assume every valid multiplayer-list response is accepted by every checker.

• MOTD content is not cited here from live third-party servers and should not be copied into articles as filler.

• A favicon or MOTD from one proxy node does not prove every backend world is healthy.

• Cache windows on public APIs bound how long a past response remains a fair claim—see the API article.

Related reading

• Online, Offline, and Unknown explained

• Minecraft server status API: fields, caching, evidence windows

• API protocol sheet

Last verified

• Evidence cutoff: 2026-07-20

• Sources re-checked: Minecraft Wiki Server List Ping (handshake, status JSON, favicon, description, protocol -1 convention); MinecraftStatus schema requirements for players