Production / Luau tools
Choose the right release copy
Start with a working Luau module and keep the editable original in your normal project history. Code protection belongs near the end of a release process, after the behavior is understood and tested. This tool prepares a distribution copy by removing ordinary comments, tightening spacing, and optionally representing string values as numeric byte escapes. It does not rename public interfaces, change your program's decisions, or run the submitted source. That makes its output easier to compare with the original than a transformation that restructures every function. Choose a small representative module first, verify the result in your intended environment, and then apply the same settings consistently to the remaining release files.
Minification follows tokens rather than text patterns
A source file contains more than words separated by spaces. A comment marker inside a message is part of that message, while a similar marker outside a string starts a comment. Removing both with a broad text replacement can change a program. The processor reads quoted strings, long-bracket strings, comments, names, numbers, and punctuation separately before assembling the result. It inserts separators where adjacent tokens could otherwise combine. Luau type annotations, compound operators, and number spellings remain in place. After transformation, the output is scanned again and checked against the expected token sequence. This is a lexical consistency check; test actual program behavior in Studio as a separate release step.
Understand what string-byte encoding changes
With string encoding enabled, ordinary quoted strings and long-bracket strings become quoted decimal-byte sequences. A three-digit escape keeps the following character from accidentally becoming part of the same escape. Text is represented using its UTF-8 bytes, and supported source escapes are interpreted before the new literal is written. Existing binary byte escapes can therefore remain byte values rather than becoming different characters. The result is less immediately readable, but the runtime still receives the original value. Interpolated strings are preserved as complete source segments, including their expressions. This deliberately leaves their nested syntax intact. The result summary reports how many strings were encoded and how many interpolated segments were preserved.
Compare byte size with a clear formula
The size report measures UTF-8 bytes rather than assuming one displayed character always occupies one byte. Reduction equals one minus output bytes divided by input bytes, multiplied by one hundred. A positive result means the generated source is smaller; a negative result means it grew. Decimal-byte encoding often expands text because a single byte is represented by a backslash and three digits. That tradeoff is expected. Select minification without string encoding when delivery size matters most, or enable encoding when reducing the immediate readability of literal text matters more. Compare both outputs for a representative module before selecting a release preset. A smaller source file alone does not establish faster game execution.
Retain useful source metadata
Compiler directives are preserved so the tool does not intentionally discard the source's requested analysis or compilation settings. License-related comments can also be retained through their dedicated option, which starts enabled. Review attribution requirements for the actual material you distribute and keep notices that your agreements require. The compact layout retains boundaries between original code lines while reducing indentation and repeated blank spacing. The source-line layout retains line breaks for easier comparison with your original and leaves multi-line string literals unchanged. Interpolated sections and preserved multi-line comments retain their own internal formatting. Choose the layout that matches your support workflow, and keep the exact generated file alongside the release record so later diagnostic messages can be investigated against the correct copy.
Keep source code security in the project design
Source transformations reduce readability; they do not make a distributed program a suitable place for account credentials, payment secrets, or private service keys. Keep sensitive authority on the server and use deliberate permission checks at the interfaces your clients can call. Preserve module exports, object names, and shared contracts when preparing a release. This tool leaves identifiers unchanged, so it does not claim scope-aware variable mangling or control flow optimization. If a project requires those transformations, evaluate a separate process that understands the full language and validates the resulting program. Maintain asset ownership records, contributor agreements, and controlled repository access as part of an intellectual property plan rather than depending on one generated file.
Use the local processing workflow deliberately
Paste source into the left editor or open a UTF-8 Lua or Luau file, then choose the options and generate a new copy. A background worker performs the transformation while the page remains responsive. Processing is limited to 512 KiB per source file to keep resource use predictable; larger projects should be prepared module by module. Copy and download stay disabled until a current result exists. Changing the source or an option marks the previous result as outdated so it cannot quietly become the next release artifact. Canceling stops the current worker. This implementation does not upload source, save it in browser storage, or execute it. Use Clear to remove editor contents when you finish. Browser tab restoration and downloaded files follow your device settings.
Finish with a reproducible release review
Run the original and generated modules through the same meaningful checks in an isolated development place. Confirm returned values, events, saved-data interfaces, text messages, and important failure paths. Include non-English strings and any binary string data your module actually uses. Compare settings and byte counts in your release notes, and retain a known working version for recovery. A generated file should be promoted only after the relevant project tests pass. If the processor reports a location error, correct the original source and try again instead of editing the output blindly. When a template or runtime feature falls outside the utility's supported scope, preserve that module unchanged until your release workflow can validate the change properly.
Language references
Review the official Luau syntax guide and the Lua lexical conventions when preparing language-specific release checks. Test generated modules against your actual runtime and project contracts.