Code Formatter writes the transformed output across multiple lines so it is easier to inspect during debugging, review, and compatibility testing. It is a diagnostic option, not a protection option — it makes protected code more readable, deliberately.
What it does
With this option enabled, the obfuscator emits a readable layout instead of packing everything tightly. That makes it practical to compare source against output while validating a build or investigating a problem. Every transform you enabled still ran — names are still mangled, strings are still in the table — you are simply looking at the result with line breaks in it.
Related options
WriteFormats_KeepIndent preserves block indentation with tabs, so nesting depth is visible.WriteFormats_LineNumbers appends original line-number hints where possible — the fastest way to map an output construct back to the source line it came from.- If
SelfCompression is enabled, formatted output is not used, because the script is packed into a self-extracting wrapper. See Compressor.
{
"options": {
"WriteFormats": true,
"WriteFormats_KeepIndent": true,
"WriteFormats_LineNumbers": true
}
}
Config aliases exist for each: formattedOutput, keepIndent, and lineNumbers. Set the alias or the raw option, not both.
Why you want this during a rollout
The first time you enable a structural transform, something usually breaks, and the difference between a ten-minute fix and an afternoon is whether you can read the output. A minified single-line file tells you nothing about where a problem is; a formatted one lets you find the construct that changed.
A workflow that works well:
- Build once with formatting and line numbers on, and keep that artifact. It is your reference copy for the release.
- Reproduce the failure against the formatted build — the same transforms ran, so the same bug is present, and now the stack trace points at a line you can open.
- Fix the cause, then rebuild without formatting for the artifact you actually ship.
- For a build you need to reproduce exactly later, pass a
seed so the formatted and unformatted builds use the same generated names.
The wider diagnostic workflow — identifier maps, demangling production traces, deciding which transform caused a regression — is covered in symbolication, the six causes of broken protected output, and verifying an obfuscator did not break your code.
Do not ship formatted output
Formatting is a real, if modest, information leak: line and block boundaries survive as structure a reader can use, and indentation shows nesting depth that a packed file hides. It also costs bytes, though gzip absorbs most of that.
Neither cost matters on a build you are inspecting locally, and neither is worth paying on a build you distribute. Make it a flag in your pipeline rather than a setting in your committed config, so a formatted artifact cannot reach production by default. Related pipeline hygiene — not shipping source maps, not shipping the identifier map next to the bundle — is in deployment hygiene and your source maps are publishing your source code.
Best for debugging: use Code Formatter on investigation builds, then turn it off again when you want the smallest or least readable production output. If you want to see what each transform does to a small sample without configuring a build at all, the
side-by-side transform viewer shows before and after for each one.