Learn · modules
What Is AntiInvis in Minecraft? (Module Explained)
AntiInvis reveals players hidden by invisibility potions or client-side render exploits, drawing a partial outline over their real position instead of nothing.
What is AntiInvis in Minecraft?
AntiInvis is a module that reveals players hiding under a potion of invisibility or a client-side invisibility exploit. Instead of showing nothing, it draws a partial outline over the hidden player's actual position, so the user knows roughly where they are without waiting for a cue like footsteps or a swung item. It sits in the exploit category, not visual or QoL, because it defeats a mechanic the game is specifically built to hide.
How it works
Vanilla Minecraft skips the render step for any entity carrying the invisibility status effect. The client still gets that entity's position, rotation, and other state over the network, since the server has to track it for hit detection and physics regardless of whether it's drawn. The game just chooses not to draw the model. AntiInvis hooks into that render step and forces it to draw anyway, usually as a flat-shaded or partially transparent outline rather than the full textured model. Because the position data was already sitting on the client, nothing extra has to be requested or sent to make this work.
The same hook also catches client-side invisibility exploits, where a modified client hides its own model locally without ever applying the real status effect to itself. AntiInvis doesn't distinguish which method produced the hidden model; it forces the outline to draw either way.
What the game hides and why
Invisibility potions are survival Minecraft's built-in stealth mechanic. A player drinks one, spends a potion slot and some duration, and the game literally doesn't draw their model anymore. The server still knows where they are (it always does), but the only way another player learns their position is through indirect cues: sounds, particle effects, a held item becoming visible, or the shape of damage numbers.
AntiInvis cancels that mechanic entirely for whoever runs it. An invisible player who spent resources on concealment is now visible to someone running the module, without the target ever knowing. That's the informational advantage it trades in.
| What vanilla shows | What AntiInvis shows |
|---|---|
| Nothing, aside from particles, armor, or a held item | A partial outline over the entity's real position |
| Position only inferable from indirect cues | Position visible directly, no cue required |
AntiInvis vs ESP
They get lumped together because both render information the game would rather you not have, but they're not solving the same problem. ESP typically punches through walls and terrain to show you entities that are simply out of your line of sight. AntiInvis doesn't touch line of sight at all: it targets one specific case, an entity the game has deliberately chosen not to draw because of the invisibility status effect (or something faking it). A fully visible player standing behind a wall is an ESP problem. A fully visible player standing in the open with a potion of invisibility active is an AntiInvis problem.
Why it counts as an exploit
A potion of invisibility exists to remove a player from view. Drinking one is a deliberate trade: an inventory slot and a status-effect duration, spent for concealment. AntiInvis cancels that trade for the user without changing anything for the target. The invisible player still believes they're hidden, still spent the resources, and gets none of the benefit against someone running the module. That's an informational and tactical advantage, not a rendering nicety, which is why it's filed under exploit rather than cosmetic or QoL.
It doesn't automate combat or movement the way a module like KillAura does. AntiInvis only changes what the user can see; they still aim, move, and fight by hand. The entire advantage lives in the information it exposes.
Is it safe to use
Hard to catch is not the same thing as safe. AntiInvis changes nothing about the packets a client sends: no new attack timing, no impossible rotations, no altered movement. Detection systems built around network behavior have nothing unusual to look at, so a purely client-side rendering change like this typically falls outside what they check for.
That doesn't make it allowed. Most servers ban invisibility-revealing modules under general fair-play or exploit rules whether or not an automated system ever flags them; enforcement can come from spectating, replays, or reports instead of a detection algorithm. Treat "hard to detect" and "allowed" as two separate questions, because servers do.
FAQ
Both. It renders a partial outline for players under the real invisibility status effect and for players using a client-side exploit that hides their model without ever applying that effect.
No. The server already sends the client an invisible entity's position and rotation for physics and hit detection. AntiInvis only changes whether that data gets drawn, nothing about outgoing packets changes.
They're related but not identical. ESP typically renders entities through walls and terrain. AntiInvis specifically targets the invisibility status effect and exploits that mimic it, and does nothing about line of sight.
Yes, even where no automated anticheat flags it. It hands you information the vanilla game deliberately withholds, and most servers ban that under general fair-play or exploit rules regardless of detection method.