About hide.lat

What the obfuscator does, and how we check it.

hide.lat is a Lua source-protection tool. Its primary language target is Roblox Luau. It accepts some Lua code from other runtimes, but a successful build does not certify that a game-specific API, native module or executor will behave correctly.

Our aim is to make distributed source harder to inspect while keeping the program's observable behavior intact. We publish the limits of that claim because developers need a reliable build more than a promise that no one can reverse their code.

What happens during a build

  1. The parser reads source into a syntax tree and handles supported Luau syntax, including type annotations, compound assignment, continue and string interpolation.
  2. The compiler transforms the program into a randomized bytecode format and packages a Lua interpreter with the result. Settings and a build seed affect the output.
  3. The service parses the generated Lua before returning it. A build report records the engine version, seed, build identifier and output hash so a release can be identified later.

Those checks catch syntax and compiler failures. They do not execute your script inside Roblox, MoonLoader or another game's runtime. If a script depends on host globals, FFI, yields, hooks or environment inspection, test the downloaded file in that exact environment before release.

What we actually test

The engine test suite compares original and protected Luau programs in the command-line Luau runtime. Its behavior cases cover arithmetic, loops, closures, upvalues, recursion, varargs, multiple returns, table operations, string methods, protected calls and Luau-specific syntax. Parser tests also round-trip a typed sample through parse and serialization. New programs can still expose compiler defects that the suite has not encountered.

The Luau command-line runtime does not contain Roblox services or executor-specific functions. We cannot claim that a command-line pass proves compatibility with game, Instance.new, LuaJIT FFI or a native hook. The Roblox guide and MoonLoader guide explain the additional checks each environment needs.

Source and account handling

The public workbench processes pasted source for the current request. It does not create a saved project, and the workbench page does not load third-party ad or analytics scripts. If you deliberately create a managed script in the dashboard, its source and build output are retained as encrypted project records so you can manage releases and access keys. These are different workflows; see the privacy notice before uploading proprietary code.

Lite is available to verified accounts. Endorser, Advanced and Maximum access is reviewed separately. Greater protection can increase output size and runtime cost, so test a representative script before selecting a tier. The release workflow gives a repeatable way to compare original and protected builds.

Limits and support

Anyone who can execute a client-side program can observe some of its behavior. Do not put secrets, payment authority or the only copy of an important security check in a distributed script. Obfuscation can slow analysis; it cannot make client code physically unrecoverable.

If a protected build differs from the original, send a minimal example, the target runtime and version, the build identifier, and the expected and observed behavior through a support ticket. Remove credentials and unrelated private source first. The free Script Doctor can help separate language syntax issues from host-runtime failures.

This page was reviewed on . Compatibility claims are updated when the compiler or test suite changes.