Entity Runtime Identifiers

When Minecraft spawns an entity, it does not just read the JSON file; it instantiates an internal C++ object to represent that entity in the world. If you do not define a runtime_identifier in your entity's description block, the game defaults to a generic base mob class. That generic class comes with basic living-mob assumptions: it has health, it can be pushed, it renders a death animation where it tips over sideways and emits white smoke particles, and it responds to standard AI goals.

By specifying a vanilla entity identifier in the runtime_identifier field, you tell the engine to construct your custom entity on top of that vanilla entity's C++ foundation instead. Your custom JSON components still load and override the data-driven parts of that entity, so you are not simply copying the vanilla mob's behavior pack file. Instead, you are inheriting the non-data-driven engine quirks that are never exposed in JSON.

This is strictly a behavior pack concept. You do not put runtime_identifier in the resource pack client_entity file. However, some runtime identifiers pass special engine values or hard-coded bone transformations down to the client renderer, so your resource pack geometry and animations occasionally need to account for the identifier you chose on the server side.

The runtime_identifier field lives directly inside the description object of your behavior pack entity file, right alongside identifier, is_spawnable, and is_summonable. Its value must always be a valid vanilla entity identifier prefixed with the minecraft: namespace. You cannot point a runtime identifier at another custom entity.

Here is a minimal setup for a custom dummy entity that uses the armor stand runtime identifier so that it does not tip over and emit smoke when killed, behaving more like a non-living prop.

{
  "format_version": "1.20.40",
  "minecraft:entity": {
    "description": {
      "identifier": "wiki:training_dummy",
      "runtime_identifier": "minecraft:armor_stand",
      "is_spawnable": true,
      "is_summonable": true
    },
    "components": {
      "minecraft:type_family": {
        "family": [ "dummy", "inanimate" ]
      },
      "minecraft:collision_box": {
        "width": 0.6,
        "height": 1.8
      },
      "minecraft:health": {
        "value": 20,
        "max": 20
      },
      "minecraft:physics": {
        "has_collision": true,
        "has_gravity": true
      },
      "minecraft:pushable": {
        "is_pushable": false,
        "is_pushable_by_piston": true
      }
    }
  }
}

While you can technically put almost any vanilla mob into runtime_identifier, most creators only ever use a small handful of them. Most standard animal or monster behaviors are already exposed as JSON components, so borrowing the runtime of a cow or a creeper rarely gives you anything you could not build cleanly yourself.

The table below covers the identifiers that remain useful in modern add-on development because their C++ behavior has no exact JSON equivalent.

Because C++ code runs underneath the JSON layer, anything hard-coded into a runtime identifier will stubbornly override or conflict with your behavior components. If you give a custom entity the minecraft:armor_stand or minecraft:boat runtime identifier, you cannot simply drop minecraft:navigation.walk and minecraft:behavior.random_stroll into its components and expect it to walk around. The underlying C++ class for an armor stand does not tick movement AI the way a Mob class does.

Sounds and item interactions are another frequent trap. An entity using minecraft:armor_stand will play wooden hit sounds and let players swap armor onto its slots unless you explicitly lock or override its equipment interaction components. An entity using minecraft:minecart will snap onto rail blocks whether you want it to or not.

On the visual side, several vanilla identifiers manipulate specific bone names in the geometry before your resource pack animations even run. For example, sheep and iron golem runtimes apply hard-coded head or body movements if your model happens to use the exact same bone names as the vanilla geometry (such as body, head, leg0). If you must use a mob runtime identifier and see weird twitching in your custom model, rename the bones in your custom geo file so the hard-coded C++ animator cannot find them.

Before reaching for a runtime identifier, check whether a modern component or Molang query solves your problem natively. Years ago, creators used minecraft:armor_stand for every piece of custom furniture just to hide the death animation, and used minecraft:ender_crystal or minecraft:shulker for solid hitboxes. Today, custom blocks with custom geometry handle furniture and solid collision cleanly without spawning ticking entities that lag the server.

Similarly, if your only goal in using minecraft:armor_stand is to stop an entity from tipping over and puffing smoke when it dies, you can often avoid the runtime identifier entirely. triggering a custom death event via minecraft:damage_sensor on fatal damage and calling a command or an instant despawn component removes the entity before the vanilla death state ever plays, letting your entity keep full access to standard mob AI and navigation.

Available in all modern Bedrock versions since 1.8.0. Does not require any experimental toggles.

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