Colouring your MOTD, chat and signs without breaking them

You wrote a MOTD, restarted the server, and the server list shows §6§lMy Server. Or worse, §6§lMy Server.

Nothing is broken. The codes are right. They are just in the wrong encoding for the file you put them in, and that one detail is behind almost every formatting problem people hit.

What a colour code actually is

Minecraft formatting is one character followed by one more character. The first is the section sign, §, which is Unicode U+00A7. The second says what to do:

§6Gold text§lBold text§cRed §lbold red

That is the entire system. Sixteen colours, five styles, and one reset. The full list shows each one drawn with its own effect applied.

The § is the problem child. It is not on your keyboard, it does not survive a copy and paste through every program, and above all it is not an ASCII character. Everything below follows from that.

The rule that trips everyone: colour resets style

This one is worth burning in, because it silently produces output that looks like a bug in your plugin.

A colour code clears every style flag that came before it.

§lBold §cRed

That is bold text, then plain red text. Not bold red. The §c wiped the bold.

To get bold red, the colour comes first:

§c§lBold red

Same two codes, opposite order, completely different result. If you have ever had a rank prefix mysteriously lose its bold halfway through, this is why. The color code generator draws the result live, so you can see it happen rather than deduce it.

§r resets everything, colour and styles alike, back to the default.

Four places, four spellings

Here is the part nobody tells you. The same message is written differently depending on where it goes.

Chat, signs, books, commands

The literal section sign, as is:

§6§lThe Nether §r§7is now open

This works in /say, in books, on signs, in most command input. If you can type or paste §, use it.

server.properties

This is the one that produces mojibake, and here is the actual reason. server.properties is a Java properties file, and Java's own documentation for Properties.load(InputStream) says the stream "is assumed to use the ISO 8859-1 character encoding; that is each byte is one Latin1 character", and that characters outside Latin-1 "are represented in keys and elements using Unicode escapes".

A literal § saved by a UTF-8 editor is two bytes. The server reads those two bytes as two Latin-1 characters. That is precisely where the stray Â comes from.

The fix is a Unicode escape, which is plain ASCII and so survives:

motd=\u00A76\u00A7lThe Nether \u00A7r\u00A77is now open

Ugly, unmistakable, and correct. Every professional-looking MOTD you have ever seen is written like this.

Plugin configuration

Almost every plugin reads & instead of § and translates it for you, precisely because & is ASCII and safe to type:

message: '&6&lThe Nether &r&7is now open'

Note the single quotes. In YAML, a value starting with & is an anchor, not text. Quote it.

/tellraw and modern commands

/tellraw does not take codes at all. It takes a JSON text component, where colours and styles are named fields:

/tellraw @a ["",{"text":"The Nether ","color":"gold","bold":true},{"text":"is now open","color":"gray"}]

That empty "" at the front matters more than it looks. In a component array, the first element is the parent and every element after it inherits the parent's formatting. Without the empty parent, the second run would inherit bold from the first and come out bold as well.

This is a genuinely easy mistake to make by hand, and it is silent. The command runs. It just renders wrong.

Getting all four right at once

The color code generator exists for this. Write the message once, watch it render in the game's own font, colours and shadow, and switch between the four outputs:

• Chat for commands, signs and books
• server.properties for the MOTD, escaped
• Plugin YAML with & codes, quoted correctly
• /tellraw as a JSON component, with the parent already in place

Obfuscated text (§k) scrambles in the preview the same way it does in game, so you can actually see what a §k prefix looks like next to real text before you commit to it.

Small things that save an evening

§ at the end of a message. A section sign with nothing after it prints as a stray character. Usually a code got half-deleted.

Unknown codes. §z is not a code. Minecraft prints it as written rather than warning you, so a typo just quietly appears in your text.

Chat length. The vanilla chat field takes 256 characters, and the codes count towards it. A message that fits until you colour it is a confusing way to find that out.

Colour before style, every time. Worth repeating, because it is the one that costs the most time.

Hex colours

Modern Java Edition supports full hex colours in JSON text components, so a /tellraw or a modern plugin can use any colour, not just the sixteen. The sixteen § codes remain the only thing that works in server.properties, on signs, and in the great majority of plugin configs.

If you need one exact brand colour in a MOTD, you do not have it. Pick the nearest of the sixteen. The reference list gives the hex and RGB of each one, so you can compare properly instead of guessing.

Sources: Minecraft Wiki, formatting codes, Minecraft Wiki, server.properties.