How a skin reaches a player
Understand saved selections, cached properties, and profile application.
SkinsRestorer 15.12.6All platformsReviewed
A skin change has three separate pieces: an identifier, a signed texture property, and the profile that the client sees.
From input to visible skin
- A command or API consumer supplies a player name, URL, or custom name.
- Skin storage resolves that input to an identifier and signed property.
- Player storage saves the selected identifier if the operation is persistent.
- The platform skin applier updates the player's profile.
- Minecraft clients download and display the texture.
A correct saved identifier does not prove that a client displays the property. A visible temporary change does not prove that the selection is saved.
Skin sources
- Player skin: Account data associated with a player UUID.
- URL skin: A generated property associated with an image URL and model.
- Custom skin: A named server entry containing a signed property.
- Recommended skin: An entry supplied by the recommendations service.
A custom entry can keep a snapshot of an account or URL texture under a stable server name.
Resolution on join
A saved player selection is separate from account skin lookup and server defaults. If no selection exists, account and default rules determine the resolved property.
Online-mode join behavior also depends on login.alwaysApplyPremium. advanced.disableOnJoinSkins prevents automatic join application.
The default list can choose one of several skins. With storage.defaultSkins.applyForPremium: false, account skins keep their normal priority over that fallback.
Caching
Player skin and UUID caches reduce service requests. Their durations use minutes. A duration of zero requests fresh data on each lookup.
Generated URL textures do not follow account skin changes. A changed PNG needs a new generation. A copied account skin can refresh with /skin update.
Proxy networks
The proxy owns ordinary commands and selections. It forwards profile data to the backends. A backend API consumer needs access to the same SQL records.
Read proxy ownership for that boundary, or persistent and temporary API changes for implementation.
Did this page help?
Last updated on