Dimensions in Bedrock Add-ons

Every Bedrock world contains exactly three hardcoded dimensions. You cannot add a fourth dimension through a behavior pack, nor can you change the build height limits or ambient lighting rules of the existing ones via JSON. Whenever a behavior pack file or script asks for a dimension, it expects one of the three vanilla identifiers.

Some JSON schemas (such as spawn rules) accept the unprefixed lowercase name, while the Script API and commands generally accept or return the full `minecraft:` namespace prefix. Keeping track of which format a system expects prevents silent failures.

Although you cannot create a new dimension, you can control which of the three vanilla dimensions your custom content appears in. Both custom feature rules (which place ores, trees, and structures) and custom spawn rules rely on biome filters to restrict where they run.

Because every biome in Bedrock is tagged with its home dimension, the standard way to lock a feature or mob spawn to the Nether or The End is to test `has_biome_tag` for `overworld`, `nether`, or `the_end` inside a `minecraft:biome_filter` component. The example below restricts a custom entity so it only spawns in the Nether.

{
  "format_version": "1.8.0",
  "minecraft:spawn_rules": {
    "description": {
      "identifier": "my_pack:magma_beetle",
      "population_control": "monster"
    },
    "conditions": [
      {
        "minecraft:spawns_on_surface": {},
        "minecraft:Spawns_lava": {},
        "minecraft:biome_filter": {
          "test": "has_biome_tag",
          "operator": "==",
          "value": "nether"
        }
      }
    ]
  }
}

Inside entity definitions, animation controllers, render controllers, and particle effects, you rarely have access to biome tags. Instead, you can check which dimension an entity is currently in using the `query.get_dimension` (or its shorter alias `q.get_dimension`) Molang query.

Wait to evaluate this query until the entity is fully initialized in the world. Actually, in practice, `query.biome_has_any_tag` is safer and more widely supported across modern Bedrock versions for checking dimension context on an entity, because biome tags travel with the chunk data. If you only need to know whether an entity is in the Overworld, Nether, or End during an animation controller transition, check the biome tag under the entity's feet.

The `@minecraft/server` module gives you direct programmatic access to all three dimensions through `world.getDimension()`. Once you hold a `Dimension` object, you can spawn entities, place blocks, run commands, or query entities within loaded chunks of that specific space.

When moving a player between dimensions—for example, when they step onto a custom portal block—you pass the destination `Dimension` inside the options object of `player.teleport()`. Remember that chunks at the target coordinates in the new dimension will not be loaded until the player arrives, so avoid running block checks at the destination before the teleport completes.

import { world, system } from "@minecraft/server";

// Teleport a player to the End when they use a custom item
world.afterEvents.itemUse.subscribe((event) => {
  const player = event.source;
  const item = event.itemStack;

  if (item.typeId === "my_pack:void_key") {
    const endDimension = world.getDimension("minecraft:the_end");
    const currentDimId = player.dimension.id;

    if (currentDimId !== "minecraft:the_end") {
      system.run(() => {
        player.teleport(
          { x: 100, y: 50, z: 0 },
          { dimension: endDimension }
        );
      });
    }
  }
});

Because Bedrock lacks true custom dimensions, add-on developers routinely fake them. There are two common techniques depending on what kind of world you are building.

The first method is the Distant Coordinate Offset. You pick a location millions of blocks away in the Overworld or The End (for instance, X: 500000, Z: 500000), generate or place a custom structure there, and teleport players to it when they enter your custom portal. Using The End for this is popular because there is no natural terrain generation at specific void gaps, and the sky is dark.

The second method is Fog and Sky Overriding. When a player teleports to your distant "dimension" area, your script uses the `/fog` command to push a custom fog definition from your resource pack onto that player. Combined with custom ambient sounds and structure generation, the player perceives a completely distinct realm even though they never left `minecraft:the_end`.

{
  "format_version": "1.16.100",
  "minecraft:fog_settings": {
    "description": {
      "identifier": "my_pack:custom_realm_fog"
    },
    "distance": {
      "air": {
        "fog_start": 10.0,
        "fog_end": 60.0,
        "fog_color": "#2A0845",
        "render_distance_type": "fixed"
      }
    }
  }
}

Applies to Bedrock Edition 1.20.0 and newer. Standard dimension queries, biome filters, fogs, and `world.getDimension()` in `@minecraft/server` 1.8.0+ are completely stable and do not require any experimental toggles.

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