Minecraft target selector cheat sheet
8 min read
Selectors are small, but they decide who receives the command. A good selector is narrow enough to be safe and simple enough to debug. Use this reference when a command works in output but hits the wrong target in game.
Guide result
A practical selector checklist that helps prevent commands from targeting nothing or too much.
Recommended path
- Choose the base selector first: nearest player, all players, all entities, or the command runner.
- Add one filter at a time, starting with type, tag, distance, or team.
- Use scores only after the objective exists and has known values.
- Add sort and limit when more than one target is possible.
- Test the selector with a harmless command before using damage, kill, teleport, or inventory changes.
Base selector decision
Use the smallest base selector that matches the job. If a command affects one player, start with the nearest player or the command runner instead of all players. If it affects entities, decide whether players should be included before using a broad entity selector.
Broad selectors are useful for setup and cleanup, but they should be paired with type, tag, team, or distance filters.
- Use @s for the command runner when executing as a known entity.
- Use @p for nearest player interactions.
- Use @a for player-wide messages or setup.
- Use @e only when entity filtering is clear.
Filters that prevent accidents
Tags are often the cleanest way to connect multi-command workflows. Add a tag when the entity is created, then target that tag later. This is easier to maintain than repeating a long NBT filter in every follow-up command.
Distance and limit filters protect commands that run from command blocks or functions. A missing distance filter can affect entities outside the encounter area.
Debug selector failures
When a selector stops matching, remove filters until it matches again. Re-add filters in order and check which one breaks the command. Scores and NBT filters are common failure points because they depend on state that may not exist yet.
NBTForge can help build the surrounding command, but in-game selector state still depends on your world, scoreboard objectives, tags, and entity positions.
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
What is the safest selector for testing?
Use @s or a tag applied to a known test entity. Avoid broad selectors such as all entities when testing destructive commands.
Why does a selector match in one place but not another?
Distance, position, executor, dimension, scoreboard state, and tags can all change between command blocks, functions, and chat commands.
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.