Guides / Commands & Data

Player heads by username: how the profile component works and why heads go blank

A head stores a skin snapshot, not a live link. Here is the profile component, why an old head shows the wrong skin, and how UUID lookup fits in.

2026-06-30

Giving a player's head sounds like it should be one argument. It is, but what gets stored is not what people expect, and that explains most head-related oddities.

The command

/give @p player_head[profile="Notch"]

The profile component replaced the old SkullOwner NBT. Snippets using {SkullOwner:"Notch"} are pre-1.20.5 and do nothing now.

What actually gets stored

A head given as profile="Notch" stores only the name. It is a dynamic profile — the item's tooltip says so — and each player's client looks the name up and fetches the skin when it draws the head. A head carries a fixed snapshot only when its profile includes the texture itself:

"profile": {
  "name": "Notch",
  "id": [I; …],
  "properties": [{ "name": "textures", "value": "<base64>" }]
}

Two consequences:

• A name-based head follows the player's current skin. It is looked up again when drawn; the client keeps a looked-up skin until it has gone unused for five minutes. Only a head carrying a textures property is frozen to one skin.
• Where it resolves is the viewer's machine. A head with a baked textures property renders with no lookup at all. A name-based head depends on each viewer's client reaching Mojang, not on the server's online mode.

Why a head is blank or shows Steve

In order of likelihood:

1. The name did not resolve for this client. Mojang's API was unreachable, or the lookup is still pending; the head shows a default skin until it does.
2. The name does not exist. Mojang returns nothing for deleted or never-registered accounts.
3. Still resolving. The lookup runs in the background, so a head can show a default for a moment after it first comes into view.

A name-based head retries on its own once its cache entry expires. To freeze a skin instead, give the head with its textures property — /fetchprofile name <name> resolves a player and offers the full component to copy, or a ready-made head to give.

Custom heads use the texture, not a name

Decorative heads — furniture, food, mob heads from catalogues — have no owner. They carry only the properties texture value with a base64 blob pointing at a texture URL. That is why they are shareable as a single long give command and why they never break when a player renames.

The base64 decodes to a small JSON containing a textures.SKIN.url on textures.minecraft.net. Nothing else in it matters for rendering.

UUID formats

Two forms exist and they are not interchangeable in every context:

trimmed   069a79f444e94726a5befca90e38aaf5
dashed    069a79f4-44e9-4726-a5be-fca90e38aaf5

Commands and NBT generally want the dashed form or an integer array. Web APIs usually return trimmed. Converting between them is mechanical — insert dashes after 8, 12, 16 and 20 characters.

Give a head from a username, browse decorative head catalogues, or convert between UUID formats in the Player Head & Username Tools.

Player Head & Username Tools →