Minecraft Server Code of Conduct: What Owners and Players Actually See

JAVA CREATOR GUIDE

See how Minecraft Java servers present a Code of Conduct, how acceptance and language fallback work, and what owners should prepare before enabling it.

Every factual statement in this guide is bounded to the exact primary sources listed below. MineBrush has not run the game, a server, a world, a datapack or a resource pack for this source-only explainer.

What a joining player sees

Minecraft Java Edition 1.21.9 documents an in-game Code of Conduct screen that a server can show during connection. The player must accept that Code of Conduct to play on the server. This is a join-flow requirement described by the release notes, not a MineBrush moderation system or a substitute for a server's broader policy process.

The same release notes say a checkbox lets a player avoid seeing the same Code of Conduct in the future. If the Code of Conduct changes, it is shown again. Owners should therefore treat content changes as player-visible revisions, not as an invisible file edit.

The switch in server.properties

The documented control is the boolean enable-code-of-conduct. When enabled, the server looks for Code of Conduct files in a codeofconduct subfolder located beside server.properties. Paper's current server.properties reference lists the same property and currently shows false as its default.

Use the exact property spelling and verify the folder relative to the server.properties file for the server instance you operate. This article does not instruct readers to change production blindly; it explains the published file contract so an owner can prepare a reviewable change.

Language filenames and encoding

The stable 1.21.9 notes say each file should use the form <language_code>.txt and be UTF-8 encoded. A review sheet should therefore list each intended language code, exact filename, encoding, and content owner. Keep the en_us file visible in that sheet because it has a specific place in fallback behavior.

Do not place formatting, translation, or legal expectations in the public guide unless they are separately supported. The Minecraft source defines filenames and encoding. Your community still needs its own editorial and governance review for the words inside those files.

The documented fallback order

Minecraft first attempts to match the player's language. If that file does not exist, it uses the en_us Code of Conduct. If en_us is also absent, the release notes say an arbitrary available entry is used. Paper's current reference describes the same progression.

That last fallback makes an incomplete language folder worth reviewing before enablement. Build a static matrix of supported player languages, available files, en_us presence, and the expected fallback source. The matrix simply applies the documented order; it does not claim a server run has occurred.

Separate the technical file from the policy

The server feature can display and require acceptance of a text file. The cited release notes do not claim that enabling it automatically writes a fair policy, supplies translations, handles appeals, satisfies local law, or enforces every rule after join. Owners should keep those questions separate from the technical setup.

Prepare a revision identifier outside the public text, record who approved each language version, and preserve the previous files for rollback. Those are MineBrush operational fields, not new claims about game behavior. Public factual statements remain limited to acceptance, repeat display, property, folder, filename, encoding, and fallback.

Owner preflight

Confirm the exact Java server version and its current property reference. Review every language file as UTF-8, confirm en_us, compare translations, and ensure the public community rules match the text players will see. Schedule the change so staff can answer questions when returning players are shown a revision again.

Before a live edit, keep a server.properties backup and the prior codeofconduct folder. A later implementation task should verify readback and join behavior on owned infrastructure. This explanatory article itself does not make a runtime claim and does not require a staged server screenshot.

Publication boundary

MineBrush can publish this explainer after independent QA because every behavior claim maps to the stable 1.21.9 release notes or the current Paper reference. The AI-generated cover is original MineBrush media and contains no game screenshot, server UI, or creator bytes.

Publication day still requires a source recheck and DLE render validation. If Mojang changes the property, location, encoding, or fallback sequence, the article must be revised before reindexing.

Code of Conduct checklist

Know what the joining player must accept. Decide whether repeat display behavior matches the intended update process. Use the documented boolean, sibling folder, language filename pattern, and UTF-8 encoding. Preserve en_us and review fallback coverage. Keep technical enablement separate from policy quality.

That checklist is intentionally narrow. It helps owners understand the official feature without overselling what a text acceptance screen can accomplish for moderation, trust, accessibility, or governance.

Design a language inventory before enabling

Create one inventory row per planned <language_code>.txt file. Record the exact code, UTF-8 confirmation, reviewer, approval state, and whether the text matches the current community policy. Add a separate en_us row and mark it as the documented fallback. This turns the published fallback sequence into a reviewable preflight without claiming a server test.

For a language not present in the folder, record which fallback the official order would reach. If en_us is missing, label the final selection as arbitrary available entry because that is the wording in the release notes. Do not pretend to know which arbitrary entry will be selected unless an exact implementation source establishes it.

Revision and returning-player communication

Because the official notes say a changed Code of Conduct will be shown again, owners should define what counts as a content revision before deployment. Preserve the prior file set, the new file set, and a private approval receipt. Announce the expected repeat screen so returning players understand why acceptance appears again.

The technical feature records an acceptance gate in the join flow, but the cited pages do not describe retention, audit export, appeals, or moderation enforcement. MineBrush should not add those claims to schema, evidence cards, or body copy. Link to the server's real policy process separately when one exists and has been reviewed.

During DLE preview, keep the distinction visible near the top: players see server-supplied text and must accept it to join, while owners remain responsible for the quality and maintenance of that text. That phrasing is consistent with the documented screen and avoids presenting a file-delivery feature as a complete trust system.

Primary sources

• Minecraft Java Team: Minecraft Java Edition 1.21.9 (checked 2026-08-25T23:09:40Z)
• PaperMC: server.properties reference (checked 2026-08-25T23:09:40Z)

Continue on MineBrush

Continue through the Java update hub or browse the Minecraft guides hub. Internal routes must pass the live DLE preview check before publication.