Home

Coloured light gives every light-emitting block a hue of its own. A torch glows warm, a soul lantern blue, a redstone torch red, and overlapping lights blend. It is off by default and is enabled with enableColoredLight in the client config, which also appears in Sodium's Video Settings.

This wiki documents how a colour is chosen and how to specify one, whether for a block, an entity, an item or a light with nothing behind it.

Sources of a colour

Requirement	Source
A block, or a family of blocks, matched by id or block tag	Resource pack colours
One blockstate coloured differently from others of the same block	Resource pack colours, the state field
A colour that moves over time	Resource pack colours, cycle
A glowing entity, a lit item, or an entity on fire	Resource pack colours, entity, item and special
A light with no block behind it, such as another mod's flashlight	Resource pack colours, behavior
Colours for a mod that may not be installed	Resource pack colours, required_mods
A colour held in block entity data, in an item, or in an attached machine	Java API
The colour a block already has, and the reason for it	How colours work

The resource pack route requires no dependency, no Java and no coordination. A mod may ship the file inside its own jar, where it takes effect only if both mods are installed. The Java API exists for colours that cannot be expressed as a function of the blockstate.

Pages

• How colours work: what a colour means to the mod, the order sources are consulted in, derivation from textures, and the settings involved.
• Resource pack colours: the JSON format in full, with matching rules, cycles, entities, items, behaviour lights and error handling.
• Java API: supplying a colour from code.

Incorrect colours

Reports go to the issue tracker. A single block being wrong, rather than every block, usually means no colour is on file for it and one is being derived from its texture, as described in How colours work.