The Minecraft Locator Bar across versions: a command reference that explains what each control actually changes

Disclosure: I built and run Locator Lab, an independent site about the Minecraft Locator Bar. It isn't an official Minecraft product and isn't affiliated with Mojang or Microsoft.

The Locator Bar is the multiplayer HUD strip that points toward other players with coloured markers. It sits in the experience bar area. It's a small feature with an unusually messy command history: two editions, three rule names and a colour system with its own priority order. Most "the command doesn't work" reports come down to running a correct command on the wrong version.

This is the reference I wish I'd had when I started keeping notes on it. It starts with a timeline, then gives a mental model with three layers, and ends with the server-side traps.

The timeline that explains most broken tutorials

Dates and versions below come from the official release notes, as collected on the site's version history page:

Date	Version	What changed
2025-04-22	Java snapshot 25w17a	locatorBar gamerule, waypoint commands and range attributes first documented
2025-06-17	Java 1.21.6	Locator Bar released on Java
2025-06-17	Bedrock 1.21.90	Player Locator Bar released on Bedrock
2025-12-09	Java 1.21.11	Game rules renamed to namespaced snake_case IDs
2026-03-24	Java 26.1	World Options added for authorized gamerule changes
2026-06-16	Java 26.2	Named team/waypoint colours must be lowercase with underscores (dark_purple)
2026-06-16	Bedrock 26.30	Old locatorbar boolean replaced by the playerWaypoints enum; old world values migrate automatically
2026-09-15	Java 26.3	Fixed MC-305422, where a waypoint packet could sometimes kick players

Two takeaways. First, any Java tutorial written before December 2025 uses a rule name that no longer exists on current versions. Second, any Bedrock tutorial written before June 2026 uses a boolean rule that's gone. The tutorials were right when they were written. They're wrong for your version now.

Layer 1: the world rule (on or off for everyone)

Edition and version	Off	On
Java 1.21.6 to 1.21.10	/gamerule locatorBar false	/gamerule locatorBar true
Java 1.21.11 and newer (including 26.x)	/gamerule minecraft:locator_bar false	/gamerule minecraft:locator_bar true
Bedrock 26.30 and newer	/gamerule playerWaypoints off	/gamerule playerWaypoints everyone

Notes that save time:

• Bedrock takes enum values, not booleans. true and false aren't valid for playerWaypoints.
• Java before 1.21.6 has no stable Locator Bar, so there's no command to give. For Bedrock versions older than 26.30, check that release's changelog rather than guessing.
• Query before you change. Running a gamerule with no value prints its current value. Save the opposite command as your rollback.

Layer 2: the sender → observer path (Java only)

This is the part that confuses people, because the world rule being on doesn't mean a particular player shows up. In Java, a marker exists only if every gate on the path from one player to another passes:

1. The sender is eligible. Sneaking, invisibility, spectator mode, and wearing a mob head or carved pumpkin can each remove a player from the bar. Spectators are hidden from non-spectators but still visible to each other.
2. The sender transmits far enough. That's the minecraft:waypoint_transmit_range attribute, which belongs to the player being located.
3. The observer receives far enough. That's minecraft:waypoint_receive_range, which belongs to the player reading the bar.
4. The observer is facing the right way. The official Java notes describe a 120° forward range, which is 60° to either side of where you're looking.

The distance check uses the smaller of the two ranges. Raising the sender's transmit range can't fix an observer whose receive range is lower, and the reverse is also true:

Transmit	Receive	Distance	Result
128	256	96	Passes (limit is 128)
64	256	96	Blocked by the sender
256	48	96	Blocked by the observer

The per-player commands:

# hide yourself from others
/attribute @s minecraft:waypoint_transmit_range base set 0
# stop seeing others
/attribute @s minecraft:waypoint_receive_range base set 0
# set a server policy distance instead of zero
/attribute @s minecraft:waypoint_transmit_range base set 128
# undo: always reset, never paste a "default" number from an old guide
/attribute @s minecraft:waypoint_transmit_range base reset

If you want to check a combination before changing it on a live server, the range simulator models the angle and the two range gates. Its marker size and height hints are illustrations, not exact vanilla pixels.

On marker appearance: marker size steps with distance, and the vertical arrows mean the other player is above or below your view. Those arrows depend on camera pitch, so a height difference alone doesn't predict them.

Bedrock doesn't share this model. Current Bedrock control is the world-level playerWaypoints rule, and Java attributes aren't valid Bedrock commands.

Layer 3: presentation (colours, packs, mods)

On Java, the colour of a marker follows a priority order:

1. An explicit waypoint colour set by command
2. The player's team colour
3. A deterministic default derived from the player's UUID

So "why is my friend's dot pink?" usually has a boring answer: nobody set a team or a waypoint colour, and pink is what their UUID produces. The colour finder works that default out from a Java username or UUID. It doesn't change your colour. It tells you which colour the game assigns. The UUID calculation runs in your browser, and username lookups aren't stored. To override the colour on purpose:

/waypoint modify @s color hex E66185
# Java 26.2 and newer: named colours are lowercase_with_underscores
/waypoint modify @s color dark_purple

The finder's algorithm is audited against Java 26.2. There's no official evidence that Bedrock uses the same default-colour algorithm, so don't use a Java result for a Bedrock player.

Resource packs and mods sit on top of all this. A pack can change or hide the HUD textures on your client, but it can't change what the server sends. Treat a pack as cosmetic, not as a privacy control.

Server traps

Console vs chat. In a dedicated server console, drop the leading slash. @s doesn't target a player from the console, so use the player's name. (A valid Java name is 3 to 16 letters, numbers or underscores.)

Paper. Vanilla commands sit behind permission nodes, and ordinary players don't get admin commands by default. Get a clean result from the console first, then grant only the specific node a role needs. Avoid wildcards, which hide what's actually missing. Multi-world setups also mean you should query the rule in the world where players are testing.

Geyser. Bedrock players joining through Geyser are on a Java backend, so the Java gamerule applies. Sending playerWaypoints to a Java server does nothing useful. Test with two Java clients first, then swap one observer for a Bedrock client. The Geyser guide has the full comparison steps.

Changes that don't survive a restart. If a value flips back, something else owns it: a hosting panel toggle, a startup script, a plugin or a world restore job. Query the value before and after a controlled restart.

A debugging order that works

1. Write down the edition and exact version, for both client and server.
2. Query the right rule name for that version.
3. Test with a second eligible player standing nearby, both in the same dimension, with no hiding states.
4. Reset both players' transmit and receive attributes.
5. Have the observer turn a full circle, then swap roles. An asymmetric result points to one player's attributes.
6. Only then restore plugins, mods and packs, one at a time.

A successful command response tells you the feature is allowed. It doesn't prove that a given player is visible. That difference causes most of the confusion.

---

I'm Kangsen Ying (yksalun). Locator Lab links each command to the release notes it comes from. If you find a version edge case it gets wrong, the corrections page is the fastest way to tell me.