Figura lets a Minecraft avatar be anything, on the client side

A client-side model replacement that other players can see

Figura is a Minecraft Java client mod, and the pitch in the README is one sentence: it lets you extensively customize your player model and have other players see your avatar without requiring any server mods.

That last clause is the whole technical trick and the whole appeal. A client mod normally changes what you see, and only you. Figura's model and animation data travel to other players as part of the normal player information the client already sends, so a server that knows nothing about Figura still renders your custom model for everyone else. No server installation, no permission from the server operator, no plugin.

The design tool is Blockbench, and the README presents the project as utilising the full potential of it, with images showing an animation editor and a mesh. The practical consequence is that the skill set required is the same as for making any Minecraft skin or custom model in Blockbench, and the format is one that already has tooling, rather than something Figura invented and asks you to learn from scratch.

The repository layout confirms this is a conventional Minecraft mod project with a multi-loader build. The top level has `common/`, `fabric/`, `forge/`, `spigot/` and `server-common/` source sets, a `build.gradle`, `settings.gradle`, `gradle.properties`, the Gradle wrapper with `gradlew` and `gradlew.bat`, a `certificates/` directory, a `CREDITS` file, and a `jitpack.yml`. The README shows supported loader badges for Fabric, Forge, Quilt and NeoForge, and the default branch is named `1.20`, after the Minecraft version it targets.

So the practical shape is: one mod, several loaders, one Gradle build that produces the variants.

The Lua API is where Figura stops being a model swapper

Beyond the model, Figura has an optional Lua API for writing your own scripts, which the README highlights separately from the Blockbench workflow. The scripts are attached to the avatar and run on the client, which means the avatar can react to the game state rather than being a static picture.

The interesting consequence is what a script can reach. A script that runs on the client has access to the world around the player, so the plausible uses are things like an animation that changes when the player is moving, an indicator that reacts to nearby entities, or a head that follows the cursor. The README does not enumerate the API surface, and the wiki at wiki.figuramc.org is where that lives, so anyone evaluating this should expect the scripting reference to be the real documentation rather than the README.

This also sets the trust boundary. If a script can read game state and drive the model, it can also be written maliciously, and it runs on the machine of whoever installs the avatar, not on the server. The permission system described further down is the project's answer to that, and it is the reason to read the permissions documentation before you accept an avatar from someone else.

The choice of Lua is deliberate rather than incidental. Lua is small, has a fast start-up, and is a common choice for embedding scripting in game clients, so a script does not need a JVM-scale runtime to be carried around with an avatar file.

The permission system, and why a small avatar needs it

The README asks a specific question: what if someone is invisible, or very small? The answer is Figura's permission system.

The problem being solved is real. If a player can attach any script and any model to their avatar, then the possibility exists of a model that is huge, or a script that reveals something the player should not reveal, and the other person in the world has no way to defend against it. A server operator cannot intervene, because the mechanism is client side and needs no server mod.

So the permissions have to live on the client and be enforced there, which means the receiving client decides what it will and will not render from a given avatar. The README shows the permission interface in a screenshot, which suggests the user can inspect and set what an avatar is allowed to do.

This is the part of Figura that most deserves a careful reading, and the part the README describes least. It does not explain what a script is permitted to do, how the receiving client decides, or what a server operator can do about a hostile avatar on their server, beyond the fact that no server mod is required and the permission system exists. If you run a server, the absence of server-side enforcement is the fact to plan around, not a detail.

For the player side, the practical advice is simple: treat an avatar with scripts as you would treat any other executable content from a stranger.

The extras, and the distribution channels

The README mentions some extras beyond the model and the scripts, illustrated with a screenshot of a radial wheel of options and another of a skull with emoji. The text does not enumerate them, so what the extras are has to be discovered from the project itself rather than from the README.

Distribution runs through the usual channels for Minecraft mods, and the README links all of them. Modrinth is the project's own page, CurseForge is the other major mod repository, and the GitHub releases page is linked as well. The homepage is on Modrinth, and the project also runs a Discord server, a website, a wiki, an OpenCollective page and a Ko-fi page for donations.

Translation runs through Weblate at translate.figuramc.org, and the README asks for help there, which is the standard way a mod with an international player base handles localisation without asking translators to open pull requests.

The repository also carries a `CONTRIBUTING.md` linked as a resource, a `CREDITS` file, and a Gitpod setup with `.gitpod.yml` and `.gitpod.Dockerfile`, which means there is a ready-made development environment for contributing without setting up a Minecraft development workspace by hand.

One detail worth flagging for anyone planning to build: the default branch is `1.20` rather than `main` or `master`. Branches named after Minecraft versions are a common pattern in the modding world, because a mod targeting several game versions usually keeps a separate branch per version, and this repository is following that convention.

The FAQ entry that tells you the file format's entry point

The README ends with a FAQ section, and only one question is included in what is written here: what to do if avatars do not appear in the Figura list even though they are in the correct folder.

The answer starts by pointing at a file: check that the avatar has a file called avatar.json, and the text is cut off mid-sentence with a reminder about checking the file extension. That single fact is the most useful piece of the FAQ, because it tells you that an avatar is a directory containing at least a JSON manifest alongside whatever Blockbench exported, and that getting the folder or the extension wrong is the usual reason an avatar is silently ignored.

The failure mode is worth pausing on. An avatar that does not load does not throw a visible error, it simply does not appear in the list, and the user is left guessing between a wrong path, a missing manifest, a malformed model or a permission block. That is why the manifest name is the first thing the troubleshooting answer checks.

What the README does not tell you is where the avatar folder should be, what the rest of the directory structure looks like, which file extensions Blockbench must be configured to export, or how the Lua scripts are laid out on disk. Those details live in the wiki, and the README is candid enough to point there rather than pretend to be complete. For anyone about to build their first avatar, the wiki is a required reading, not optional documentation.

Version tags, a custom licence, and what the 0.1.6 line tells you

The release history is short and recent. The three listed releases are 0.1.6 on 2026-06-19, 0.1.6-rc.3 on 2026-06-15 and 0.1.6-pre.2 on 2026-06-09, and the last push to the repository was on 2026-10-06.

The shape of those tags is informative. A release candidate and a pre-release, both in the same week, followed by the final release a few days later, is the pattern of a project that iterates quickly and publishes on its own schedule rather than following the Minecraft release cycle. The version number being at 0.1.6 tells you the project treats itself as pre-1.0, which is consistent with a feature set that is still expanding, including the Lua API and the permission system.

The licence is the item to look at. GitHub cannot classify it, and the repository has a `LICENSE.md` file, so the terms are in a custom document rather than a standard MIT or GPL file. For a mod that distributes user-generated content, including scripts, a custom licence is not unusual, and the one in `LICENSE.md` is the authoritative text. Read it yourself, especially the terms covering avatars and scripts, before you publish content or redistribute anything.

The build itself is a Gradle project, so building from source means using the wrapper, and the `jitpack.yml` file suggests the project is set up to be consumed as a library through JitPack, which is how some modders depend on Figura's shared code.

Taken together, the picture is of an active project on a fast release cadence with an unusual licence and a documentation model that pushes the details to a wiki rather than the README.

Editorial conclusion

Adopt Figura if you want a custom player model that other people see on vanilla or modded servers, and you are comfortable compiling a client mod or installing one from Modrinth or CurseForge. Do not adopt it as a server operator who wants to control what clients display, because the whole mechanism runs on the client and the README states that no server mods are required, which also means the server cannot enforce it. Before you publish an avatar, check the permission rules for other players who are invisible or scaled down, read the LICENSE.md file yourself since GitHub cannot classify the licence, and confirm that your Blockbench model includes the avatar.json file the FAQ points to.

Frequently asked questions

Official sources

1. FiguraMC/Figura on GitHub
2. Issues
3. Project website
4. README
5. Releases