Slim or classic is decided by 24 pixels, and you can see exactly which ones
A skin is slim if fewer than 6 of the 24 pixels at (46,20)–(47,31) are opaque. Plus the full UV map, why legacy 64×32 skins get mirrored, and why Bedrock's 128×128 will never load in Java.
Nothing in a skin PNG says "slim". There is no flag, no metadata and no filename convention — the model is inferred from the image itself, by looking at a specific 2 × 12 rectangle and counting how many of its pixels are actually there.
The test
sample x 46–47, y 20–31 — 2 wide, 12 tall = 24 pixels
count pixels with alpha > 0
slim if fewer than 6 are opaqueClassic arms are 4 pixels wide; slim arms are 3. A slim skin therefore leaves the fourth arm column empty, and that column is what the sample sits over. Twenty-four pixels decide which model your character wears.
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 the fourth column — 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, that column is the place to look.
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:
| part | base | overlay | offset | size |
|---|---|---|---|---|
| head | (8, 8) | hat (40, 8) | 32 right | 8 × 8 |
| body | (20, 20) | jacket (20, 36) | 16 down | 8 × 12 |
| right arm | (44, 20) | sleeve (44, 36) | 16 down | 4 × 12 |
| right leg | (4, 20) | trousers (4, 36) | 16 down | 4 × 12 |
| left arm | (36, 52) | sleeve (52, 52) | 16 right | 4 × 12 |
| left leg | (20, 52) | trousers (4, 52) | 16 left | 4 × 12 |
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 rectangles do not move; only the width read out of them changes.
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.
Bedrock's 128 × 128 is a different format, not a bigger one
Java accepts 64 × 64 or legacy 64 × 32. Bedrock accepts 128 × 128 and nothing else. Neither edition's viewer can display the other's file — this is not a resolution difference that scales, it is a different UV layout at a different size.
That is a hard wall rather than an inconvenience. A Java skin does not "upscale" to Bedrock, and a Bedrock skin loaded into a Java viewer does not render at half size — it is rejected. The editor on this page treats the two as separate builds for exactly that reason.