Crafatar alternative
Switching from Crafatar or Minotar is a change to the URL you build, not to your app. Here is every endpoint next to the one that replaces it, and the handful of differences worth knowing before you swap.
/face /head /body Crafatar, URL for URL
Same player, same picture, different path. Everything below takes the identifier you already have.
| Crafatar | Skin Render | Notes |
|---|---|---|
/avatars/{uuid}?size=64 | /render/{uuid}/face?size=64 | The flat face. Overlays are drawn by default here, so ?overlay has no counterpart; hat=false removes it. |
/avatars/{uuid}?overlay | /render/{uuid}/face | Same image at the default 256 px. |
/renders/head/{uuid} | /render/{uuid}/head | The 3D head. yaw and pitch move the camera instead of one fixed angle. |
/renders/body/{uuid} | /render/{uuid}/body | The full model, with poses and a cape if the profile has one. |
/skins/{uuid} | /render/{uuid}/skin?size=64 | The raw texture. size=64 is the file itself; without it you get a 256 px upscale. |
/capes/{uuid} | /render/{uuid}/cape?size=16 | The cape, or a fully transparent PNG when the profile has none. |
// before
const avatar = `https://crafatar.com/avatars/${uuid}?size=64&overlay`;
// after: overlays are already on, and a username works as well as a UUID
const avatar = `https://skinrender.dev/render/${uuid}/face?size=64`; Minotar, URL for URL
Minotar puts the size in the path; here it is a query parameter, which is what lets the same URL carry a camera and a pose as well.
| Minotar | Skin Render | Notes |
|---|---|---|
/avatar/{name}/64 | /render/{name}/face?size=64&hat=false | The face without the hat layer, which is what /avatar leaves off. |
/helm/{name}/64 | /render/{name}/face?size=64 | The face with the hat layer: the default here. |
/bust/{name}/100 | /render/{name}/bust?size=100 | Head, torso and arms. |
/body/{name}/100 | /render/{name}/body?size=100 | The whole model. |
/cube/{name}/100 | /render/{name}/head?size=100&yaw=45&pitch=30 | The isometric cube is a camera angle rather than a separate type. |
/skin/{name} | /render/{name}/skin?size=64 | The raw texture. |
Visage’s /face/<size>/<uuid>, /bust/… and /full/… map the same way, onto face, bust and body with size.
The differences that bite
- Overlays are on by default. If your Crafatar URLs carry
?overlay, drop it. If they do not, and you want the bare skin, addoverlay=false— orhat=falseto lose only the hat. - Names as well as UUIDs. A username, a dashed or dashless UUID, a texture hash, or
steveandalexfor the default skins. Whatever you have is enough. - The angle is yours. Where the old endpoints each give one framing,
yaw,pitch,fovandzoomare parameters, andpose=waveor a per-joint angle changes the model itself. That is the reason to switch rather than the compatibility. - Missing capes are not errors. Most profiles have no cape;
/capeanswers200with a fully transparent PNG rather than failing, so an<img>on a profile card never breaks. The profile endpoint tells you in advance whether there is one. - A missing player still renders. An unknown name or a player who never set a skin gives you Steve or Alex with an
X-Skin-Fallbackheader;default=noneasks for a 404 instead. - The URL can end in
.pngif whatever you are pasting it into insists on an extension. It is the same request either way.
Swapping in practice
Change the URL builder in one place, keep your identifiers, and check three things: that overlays look the way you want, that the sizes still suit your layout (size is the height and the width follows the type, up to 1024), and that whatever caches for you sees the new URLs. Nothing else in your app has to move. The playground is the fastest way to land on the exact URL you want, and the link it gives you carries the settings, so you can paste the finished thing straight into your code.
Frequently asked questions
Is Skin Render a drop-in replacement for Crafatar?
Not a drop-in: the path shape is different, so you change the URL you build rather than only the host. Everything Crafatar renders has an equivalent here, and the identifiers you already store keep working.
Do usernames work?
Yes. https://skinrender.dev/render/Notch/face resolves the name for you. Crafatar answers Invalid UUID for a name, which is the usual reason people keep a name-to-UUID lookup of their own; you can drop it, or use the profile endpoint if you want the UUID itself.
What happens to my stored UUIDs?
Nothing. Dashed or dashless UUIDs both work, and so do 64-character texture hashes if you cached those — a hash renders without any profile lookup and is served as immutable.
Is there a key or a rate limit to plan for?
No key and no per-caller limit on our side. Renders are deterministic and carry an ETag, so a CDN or your own cache in front of them costs you nothing to add.
Related documentation
- Render types: Every render type of the Minecraft skin API (face, head, bust, full body, front, back, skin and cape) with its default size, parameters and live example URLs.
- Parameters: Every query parameter of the Minecraft skin render API: size, camera yaw and pitch, fov, layers, capes, poses, per-joint angles and fallbacks, from the code.
- Examples: Copy-paste Minecraft skin render examples: profile pictures, Discord bot embeds, forum signatures, server list cards, textures by hash and animation frames.
- Caching & limits: How the skin cache works: profiles for 15 minutes, textures for a day, rendered PNGs for an hour. Plus the headers to rely on, Mojang rate limits and errors.
- Playground: build any of these URLs by clicking.