Guides / Building & Resources

Slim or classic: the game reads your account, and a tool has to guess from 24 pixels

The game takes slim or classic from your account's skin setting, not the PNG. A tool given a bare PNG has to guess from two columns a slim arm leaves empty. Plus the full UV map and why legacy 64×32 skins get mirrored.

2026-08-01

Nothing in a skin PNG says "slim". There is no flag and no filename convention — and the game never looks at the pixels to find out. It takes the model from the model setting your account attaches to the skin (the choice you make when you upload it), and a profile with no skin gets one of 18 default skins, 9 slim and 9 classic, picked from its UUID.

Only a tool handed a bare PNG — an editor, a pack builder, a viewer — has to infer the model, and it does it by looking at a specific 2 × 12 rectangle and counting how many of its pixels are actually there.

The test

sample  x 54–55, y 20–31        — 2 wide, 12 tall = 24 pixels
count   pixels with alpha > 0
slim    if fewer than 6 are opaque

Classic arms are 4 pixels wide; slim arms are 3. A slim arm's faces are packed one pixel narrower, so the side and back faces shift left and the last two columns of the arm block, x 54–55, are left empty. On Mojang's own default skins that rectangle is 0 of 24 opaque on all nine slim ones and 24 of 24 on all nine classic ones — twenty-four pixels are enough to tell.

The threshold is 6 of 24, not 1 — a quarter of the column has to be filled before it counts as classic. That tolerance matters: a slim skin with a few stray pixels in the dead column still reads as slim, which is what you want, because those strays are almost always an editing accident rather than an intention.

It also means the failure mode is quiet. If you draw a classic skin but only lightly use those columns — a thin outline, a couple of shading pixels — you can land under 6 and be auto-detected as slim, losing a pixel of arm width with nothing to explain why. If a skin comes out the wrong model in a tool, those columns are the place to look — and in the game, the setting on your account is.

The UV map, in full

Every part of the skin is a fixed rectangle, and each has an overlay layer somewhere else on the sheet:

Five of the six overlays sit exactly 16 pixels from their base — but not in the same direction. The three original parts go 16 down. The left arm and left leg, added later and squeezed into the bottom half where there was no room below them, go 16 sideways instead — and in opposite directions from each other.

The hat is the only one that is not 16 away at all: it is 32 to the right, on the same row as the head.

So "the overlay is under the base" is a rule that holds for exactly half the sheet. Copying a base rectangle and offsetting it downward to find its overlay works for the body, right arm and right leg, and silently lands on the wrong part for the other three.

On a slim skin every 4-wide arm rectangle is read as 3 wide instead. The front faces do not move, but everything after them does: the side face and the back face each start one pixel further left, and the back face is a pixel narrower, which is what leaves x 54–55 empty.

Legacy 64 × 32 has no left side at all

A pre-1.8 skin is 64 × 32 — the bottom half of the sheet simply does not exist, which is where the left arm and left leg live. There is nothing to draw them from.

The fix is mirroring: the right leg (0, 16) is copied to (16, 48) and the right arm (40, 16) to (32, 48), both flipped horizontally. That is why old skins are perfectly symmetrical and modern ones need not be — asymmetry is the one thing the 64 × 32 format cannot express, and any old skin you convert gets symmetry imposed on it whether it wants it or not.

A 128 × 128 editor file is the same layout, twice the size

Java accepts 64 × 64 or legacy 64 × 32 and rejects anything else. This site's Bedrock skin editor works at 128 × 128 and accepts nothing else — but that file is the same UV layout drawn at twice the resolution, every part at double the Java coordinates, not a different format.

The wall is in the tools, not the layout. Each editor build's texture pipeline is sized to its own number, so neither will open the other's file, and a 128 × 128 PNG handed to Java is rejected rather than shown at half size. Converting is a mechanical 2× scale, which is why the skin editor treats the two as separate builds rather than one canvas.

Avatar Maker →