Dynamic Displays with Rawtext and Commands

At the heart of every command-driven display in Bedrock is the rawtext JSON object. Unlike plain text commands such as say or title, rawtext commands (tellraw and titleraw) parse a JSON payload before rendering it to the screen. This payload accepts an array of component objects that the game evaluates at the exact tick the command runs, stitching the results together into a single continuous string.

Each object inside the rawtext array performs one specific job: rendering a literal string, looking up a translation key from a language file, resolving the names of entities matching a target selector, or pulling an integer value from a scoreboard objective. Because the array is evaluated sequentially, you can mix static labels, formatting codes, and live variables in a single command call.

When writing rawtext inside a behaviour pack function file (.mcfunction), the entire JSON structure must be collapsed onto a single line following the command arguments. Below is the expanded, formatted structure of a valid rawtext payload to show how the different object types sit side by side inside the main array.

{
  "rawtext": [
    {
      "text": "§6Player: §f"
    },
    {
      "selector": "@p"
    },
    {
      "text": " §7| §aCoins: §f"
    },
    {
      "score": {
        "name": "@p",
        "objective": "coins"
      }
    },
    {
      "text": "\n§eStatus: "
    },
    {
      "translate": "hud.status.ready",
      "with": [
        "5"
      ]
    }
  ]
}

The most common place for a dynamic display is the action bar—the small region directly above the player's hotbar. Unlike the main center-screen title and subtitle slots, the action bar does not obstruct the player's crosshair and supports multiline text using the \n escape sequence. By running a titleraw command targeting the actionbar slot every tick (or every few ticks), you create a persistent heads-up display that updates immediately whenever a player's score changes.

A critical quirk arises when you try to display each player's own score to them in multiplayer. If you run a single titleraw @a actionbar command and put @s or @p inside the score component's name field, every player on the server will see the exact same score—specifically, the score of whoever executed the command or whoever was closest to the command's execution origin. This happens because the command resolves the rawtext payload once from the executor's context before broadcasting the resulting text to the target audience.

To show individualized scores, you must shift the execution context to each player individually before calling titleraw. Wrapping the command in execute as @a run titleraw @s actionbar forces the game to evaluate the rawtext payload separately for every online player. In that context, @s inside the target argument and @s (or *) inside the score component both refer to the specific player currently being processed.

# Ensure objectives exist before attempting to display them
scoreboard objectives add coins dummy "Coins"
scoreboard objectives add mana dummy "Mana"
scoreboard objectives add timer_min dummy "Minutes"
scoreboard objectives add timer_sec dummy "Seconds"

# Execute as each player so @s resolves to the individual viewer
execute as @a run titleraw @s actionbar {"rawtext":[{"text":"§6Coins: §e"},{"score":{"name":"@s","objective":"coins"}},{"text":"   §bMana: §f"},{"score":{"name":"@s","objective":"mana"}},{"text":"/100\n§7Time Remaining: §f"},{"score":{"name":".global","objective":"timer_min"}},{"text":":"},{"score":{"name":".global","objective":"timer_sec"}}]}

When you want a display to exist at a physical coordinate in the world—such as a leaderboard in a lobby, a price tag above a shop chest, or a generator countdown—you use a dummy entity's custom name tag. In Bedrock Edition, any entity with an active minecraft:nameable component can display a floating string above its bounding box. By making the entity invisible and non-interactive, only the floating text plate remains visible to players.

While vanilla commands cannot directly inject a rawtext JSON object into an entity's CustomName field, you can build a custom dummy entity in your behaviour pack for the sole purpose of holding text, or use the Script API to bind rawtext strings to its nameTag property. Even without scripts, you can create state-based dynamic displays using entity events: define component groups in the entity JSON with different preset name tags, or toggle the minecraft:is_baby, minecraft:variant, or minecraft:skin_id components if your resource pack uses them to drive custom geometry or UI.

The entity definition below establishes a stable, lag-free floating text anchor. It disables gravity and collision so the text never falls or pushes players, applies the minecraft:damage_sensor component to make it completely immune to all damage sources (including /kill if you choose, though keeping it vulnerable to void/command damage is safer for cleanup), and sets always_show to true on the nameable component so players do not have to aim their crosshair directly at the invisible hitbox to read the display.

{
  "format_version": "1.19.50",
  "minecraft:entity": {
    "description": {
      "identifier": "wiki:floating_display",
      "is_spawnable": false,
      "is_summonable": true,
      "is_experimental": false
    },
    "components": {
      "minecraft:type_family": {
        "family": [
          "display",
          "inanimate"
        ]
      },
      "minecraft:collision_box": {
        "width": 0.0,
        "height": 0.0
      },
      "minecraft:physics": {
        "has_gravity": false,
        "has_collision": false
      },
      "minecraft:pushable": {
        "is_pushable": false,
        "is_pushable_by_piston": false
      },
      "minecraft:nameable": {
        "always_show": true,
        "allow_name_tag_renaming": false
      },
      "minecraft:damage_sensor": {
        "triggers": [
          {
            "cause": "all",
            "deals_damage": false
          }
        ]
      },
      "minecraft:knockback_resistance": {
        "value": 1.0
      }
    }
  }
}

Rawtext score components only output raw integers; they cannot natively change colour when a number drops low, nor can they draw graphical progress bars on their own. To build visual bars (like [████░░░░░░]) or colour-shifting warnings in pure commands, you combine score range selectors with multiple titleraw lines.

The technique relies on the scores={} target selector argument. Instead of running one unconditional titleraw command for everyone, you write a sequence of execute commands that filter players by their exact score bracket. Each bracket runs its own tailored titleraw payload with hard-coded section-sign colour codes and block characters matching that specific percentage range.

This pattern is ideal for capture-point progress, boss health bars on the action bar, or overheating gauges. Because only one score range matches a player on any given tick, only one titleraw command fires for that player, preventing flickering. You can still embed live score components inside each bracketed command so the exact numerical readout updates smoothly alongside the stepped visual bar.

# Display a stepped progress bar and colour-coded percentage based on 'capture' score (0 to 100)

execute as @a[scores={capture=0..24}] run titleraw @s actionbar {"rawtext":[{"text":"§cCapture Progress: [■■□□□□□□] "},{"score":{"name":"@s","objective":"capture"}},{"text":"%"}]}

execute as @a[scores={capture=25..49}] run titleraw @s actionbar {"rawtext":[{"text":"§6Capture Progress: [■■■■□□□□] "},{"score":{"name":"@s","objective":"capture"}},{"text":"%"}]}

execute as @a[scores={capture=50..74}] run titleraw @s actionbar {"rawtext":[{"text":"§eCapture Progress: [■■■■■■□□] "},{"score":{"name":"@s","objective":"capture"}},{"text":"%"}]}

execute as @a[scores={capture=75..99}] run titleraw @s actionbar {"rawtext":[{"text":"§aCapture Progress: [■■■■■■■□] "},{"score":{"name":"@s","objective":"capture"}},{"text":"%"}]}

execute as @a[scores={capture=100..}] run titleraw @s actionbar {"rawtext":[{"text":"§b§lCapture Complete: [■■■■■■■■] 100%"}]}

Hard-coding English strings inside your .mcfunction files makes it difficult to translate your add-on later and clutters your command logic. Using the translate and with keys inside rawtext lets you move all display text into your resource pack's texts/en_US.lang file while still injecting live scoreboard numbers and player names at runtime.

In the .lang file, you define placeholders using standard positional tokens: %s for unnumbered sequential replacements, or %1$s, %2$s, and so on when you need to control the exact order in which variables appear in different languages. When the game processes a translate component in rawtext, it takes the companion with key, evaluates every element inside it, and slots the results into those %1$s tokens.

Crucially, if you want to pass dynamic data like a score or a target selector into a translation placeholder, the value of with must be a nested {"rawtext": [...]} object rather than a simple string array. Each top-level item inside that inner rawtext array becomes one positional argument (%1$s, %2$s, etc.) for the language string.

display.bounty.claimed=§e%1$s §7claimed the bounty on §c%2$s §7for §6%3$s Coins§7!
display.hud.stats=§aLevel: §f%1$s §8| §dXP: §f%2$s/%3$s

A dynamic display is only as responsive as the loop that triggers it. While repeating command blocks work for single-world maps, a portable behaviour pack should drive its display functions through BP/functions/tick.json. Any function path listed in this file executes automatically once per game tick (20 times per second) from the server context.

Running heavy selector queries and titleraw commands 20 times a second for every player is generally fine for small groups, but on larger realms or servers it is cleaner to throttle your display updates. Humans rarely notice if a coin counter or timer updates every 4 or 5 ticks instead of every single tick, and throttling keeps the action bar's native fade-out timer refreshed without saturating the command execution queue.

You can build a lightweight throttle inside your main tick function by incrementing a fake player score (such as .tick_counter) by 1 every tick, running your HUD update function only when that score matches a target number, and immediately resetting the counter back to 0.

{
  "values": [
    "hud/update_actionbar"
  ]
}

Applies to Minecraft Bedrock Edition 1.19.50 and newer (using the updated execute command syntax). Rawtext commands (tellraw, titleraw) and tick.json are fully stable features and do not require any experimental toggles.

Read out of the game itself, so the ids match the version you are building for.