Mixins are a powerful and important tool used in the Fabric ecosystem and other modding frameworks for Minecraft. Their primary use case is modifying existing code in the base game, whether it be through injecting custom logic, removing mechanics, or modifying values. Note that only Mixins written in Java are directly supported, even if you use Kotlin or another language running on the Java Virtual Machine for the rest of your mod. Whilst it may be technically be possible to use other JVM languages apart from Kotlin which is explicitly unsupported, there are currently no plans to support it or document such a process.

Mixin is a complex subsystem which merges a mod's mixin “classes” ¹⁾ into the targeted classes' compiled Bytecode at runtime by parsing the mixin classes' compiled bytecode. It will merge both the annotated methods, and other members and interfaces added to the Mixin class. The specifics of how this is done is outside the scope of this introduction, refer to the relevant Mixin Wiki links on this page for details.

It is not recommended to try and learn how Mixin works or how to use it without having some notion of what Bytecode is, as that may lead to unexpected behavior and misunderstandings. It is also recommended to know how to read Java Bytecode for your IDE of choice, as reading portions of the Bytecode may sometimes be necessary to use Mixin properly, notably when targeting anonymous classes, lambdas or code with a lot of if-else logic branching.
Similarly, Mixin and this documentation expects the user to already be familiar with Reading Minecraft and external source code, and be able to set up an initial development environment, aswell as having a decent understanding of Java fundamentals. If, however, you specifically wish to skip to examples, be aware that it is expected for you to encounter difficulties and confusion in your learning process as you try to tackle more technical issues without learning some technical aspects, and you are likelier to need direct support.

Mixin does its work very early in the overall Fabric launching process, and must be, in rough terms, fully applied before the code it targets is actually “in use”. By the time a client sees the title menu or a server becomes joinable, Mixin has already attempted to complete all the work it could. This does not at all guarantee Mixin applied all patches as intended by the devs or that no patches were cancelled. It only means Mixin will not modify the game any further after that point.

There are different kinds of tools Mixin and MixinExtras ²⁾ provide for modifying source code. Those tools come in the form of Java annotations, those annotations decorate³⁾ members of the Mixin class and are passed arguments which are used to associate the necessary information so that Mixin knows how to process your class and then transform and merge them into the target class. Here is a basic overview of Mixin's important annotations:
There ought to be dedicated pages going more in depth about the different tools annotations later on. This segment as it is edited should be kept to an introductory level to Mixin annotations and features.

• The @Mixin annotation decorates every Mixin class. It mainly dictates the class to target and the priority of the decorated class relative to other mixin classes with the same target.
• Injector Mixin annotations decorate a handler method⁴⁾ and will inject it into the target class and then call it at the injection point. Injectors are distinguished by the fact they do not overwrite the targeted bytecode⁵⁾, injectors include all method decorations from MixinExtras, and in base Mixin mainly @Inject, @ModifyVariable or @ModifyArg.⁶⁾ Injectors should be treated your primary way to modify external code as they are more compatible (more than one mod can inject the same target), and MixinExtras provides injector alternatives that fulfill nearly all roles of non-injector tools such as redirectors/redirect injectors and overwriting.
• Redirector Mixin annotations refers to annotations that merge the handler method and replace the targeted injection point with a call to your handler method. Think of it as overwriting what you targeted and replacing it with a call to the decorated handler method. Whilst a name for them is also Redirect Injectors, you should generally treat them differently as they do not merely inject but also overwrite information and cannot chain.⁷⁾ The main redirectors are @Redirect and @ModifyConstant.
• Overwriting, using the @Overwrite annotation simply replaces the targeted method with your own. There is practically never any reason to use this as a mod developer, and you should always prioritize other solutions like MixinExtras' @WrapMethod.
• Mixin also merges the vast majority of aspects of the Mixin class even if there are no dedicated methods. For instance, you may make your Mixin class implement an interface its target class or its parents do not implement, and it will be merged into the target. This can also be done with fields and methods. If in doubt about whether something gets merged or how it should be merged, it's likely best to directly ask for advice for your specific case in support channels.

For more complete and thorough information on Mixin functionality, usage, and mechanics, view the Mixin Official Wiki. Additional documentation can be found in the Mixin Javadoc. MixinExtras features are documented on its Official Wiki. JavaDoc documentation may be found in your local development environment with Mixin set up aswell.

The Fabric Wiki offers several articles that provide practical examples and explanations of some areas of the Mixin and MixinExtras tools:

• Mixin registration
• Injects
• Accessors and Invokers
• Redirectors
  • Method redirectors
• Tips (WIP)
• Examples
• Hotswapping Mixins
• Exporting Mixin Classes
• Access Wideners
• Reflection
• Interface Injection
• Modding Tips