Minecraft text component color and click guide
9 min read
Minecraft text components show up in more places than tellraw. The same writing decisions affect titles, actionbars, item names, lore, books, bossbars, teams, and display entities. NBTForge keeps visual text editing close to command output so readable messages do not become quote-heavy JSON chores.
Guide result
A readable text-component workflow for player messages, item tooltips, books, titles, and bossbars.
Recommended path
- Write the message in plain language before adding color or click behavior.
- Use color to separate meaning, not every word.
- Keep item names shorter than lore lines and keep lore lines scannable.
- Add hover and click behavior only when the command surface supports it.
- Preview output after each text edit because nested JSON can change quickly.
Color and decoration rules
Use one main color for the message and one accent color for state, danger, reward, or action. Too many colors make command output harder to read and player text harder to parse.
Bold, italic, underlined, and obfuscated styling should be intentional. For map UI, emphasis should help the player understand what changed.
- Reserve red or dark red for danger or failure.
- Use gold or yellow for rewards and objectives.
- Use gray for secondary context.
- Avoid decoration on long body text.
Click and hover behavior
Click events are useful for commands, links, suggestions, and navigation prompts, but they can surprise players if the visible text does not describe the action. Put the action in the text, not only in the hover tooltip.
Hover text should add context. It should not carry the only important instruction because some players will not hover every message.
Reuse text across surfaces
The same quest title can become a title command, a tellraw line, an item lore hint, and a written book entry. Keep wording consistent across those surfaces so players recognize the objective.
When the same message appears in several command families, save each command to Project with a shared naming convention.
Ship the copied artifact
Use this guide to produce the artifact a player or map maker will actually run: a copied command, ordered Project pack, or datapack resource. The final review should happen on that copied output, not only on the editable builder state.
When the workflow is version-sensitive, label the target version beside the command. When it uses selectors, scoreboards, bossbars, tags, loot tables, or project order, test those dependencies in a clean world before publishing the setup.
- Copy from Output for one command and from Project for ordered packs.
- Keep Java, Bedrock, and snapshot variants separate.
- Test destructive selectors with harmless output first.
- Update related presets when the guide becomes the canonical workflow.
Related guides and presets
FAQ
Can every text surface use click events?
No. Some surfaces support richer JSON behavior than others. Build the text in the relevant NBTForge module and check the generated output before assuming a feature is available.
Why does item lore look different from chat text?
Item tooltips have different space, line length, and readability constraints. Lore should usually be shorter and more structured than chat or book text.
When should this guide become a Project pack?
Use Project when the workflow needs more than one command, has setup and cleanup order, or must be edited again after testing. One-off commands can stay in Output.