Minecraft Color Codes: §, JSON, and Hex Gradients

Verified: Java 26.3 / Bedrock 26.50 · 2026-09-16 · Updated 2026-09-16

Minecraft has not one text-coloring system but three stacked on top of each other, and most broken formatting comes from using the right code in the wrong layer. This guide separates them — the legacy § codes, vanilla Java's JSON components, and the server-side hex conventions — so the color code generator's three outputs make sense.

Layer one: the sixteen § codes

The oldest system is a section sign plus one character: §0 through §f for colors, §k through §r for formats. It works in chat (where allowed), on signs, in item names, and in server MOTDs, and both editions understand the core of it. The sixteen colors are fixed — there is no legacy code for an arbitrary hex value — and their exact shades are worth knowing because every other tool in the ecosystem maps to them: gold is #FFAA00, aqua is #55FFFF, and the four "dark" colors are the same hue at #AA instead of #55 intensity. The full table sits on the tool page, verified against the Minecraft Wiki's formatting-codes documentation (minecraft.wiki/w/Formatting_codes), which is where the sixteen names and hex values come from.

One edition split hides in the format codes. Java uses §m for strikethrough and §n for underline; Bedrock assigns those same two codes to material colors — redstone and copper — and simply has no strikethrough or underline. Bedrock also carries extra colors Java lacks, most famously §g, minecoin gold. If a design leans on §m or §n, it is a Java-only design.

Layer two: JSON text components (Java 1.16+)

Vanilla Java commands — tellraw, title, written books, signs — take JSON text components, and since Java 1.16 the color field accepts any hex value: {"text":"hi","color":"#FF8800"}. This is the only vanilla route to colors outside the sixteen, and it is what the generator's JSON output produces. Formats become boolean fields (bold, italic, underlined, strikethrough, obfuscated) rather than inline codes, which is why the JSON output looks structural while the legacy output looks like a prefix soup.

The gradient builder is this layer used at full stretch: one component per character, each with its own interpolated hex. The interpolation is plain linear RGB — each channel walks from the start value to the end value in equal steps, rounded half-up — and the math is asserted character by character in our test suite, including the fact that a space gets no color of its own.

Layer three: server conventions

Two facts save most server headaches. First, server.properties is a Java properties file, so a raw § pasted into the MOTD line tends not to survive; the durable form writes each section sign as the escape \u00A7, which is exactly what the generator's MOTD output emits. Second, the popular server platforms accept hex in chat and MOTDs through their own conventions — the widely used long form spells the hex out as §x followed by each digit with its own section sign. Those conventions belong to the server software, not to vanilla Minecraft, and they vary by plugin, which is why the generator sticks to the two vanilla-true outputs and leaves plugin formats to the plugin's own docs.

A worked example

Say you want a gold, bold server name. Legacy: §6§lTorch and Anvil. MOTD line: \u00A76\u00A7lTorch and Anvil. JSON: {"text":"Torch and Anvil","color":"gold","bold":true}. Three spellings, one result — and if you instead want the name to fade from gold #FFAA00 to red #FF5555, only the JSON layer can do it in vanilla: fifteen characters get fifteen interpolated colors, the midpoint landing at #FF802B. That midpoint is one of the fixtures our tests pin.

Sources

The code table, the Bedrock §m/§n reassignment, and the Bedrock extras come from the Minecraft Wiki's formatting-codes page, re-checked 2026-09-01; the Java 1.16 hex-in-JSON fact is documented on the wiki's text-component page and confirmed by multiple server-tooling references, which also document the properties-file escape. Where the server-side hex conventions vary, this guide says so instead of picking one.