Documentation

Code Formatter

Reference guides for release workflows, command-line usage, cross-file protections, and the desktop app.

Inside the Docs

Practical guides for real release work.

How-to guides Start with release sequencing and command-line usage, then move into feature-specific references.
Advanced protection Browse cross-file controls like Replace Globals and Protect Members when a build spans multiple scripts.

Code Formatter

  • WriteFormats
  • Free

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.

Frequently asked questions

Does formatted output mean the protection was not applied?

No, and this is the most common misreading of the option. Every transform you enabled still ran: identifiers are still mangled, string literals are still in the table, and any structural transform still rewrote what it was going to rewrite. The only difference is that the result is emitted across multiple lines instead of packed tightly. You are looking at the same protected code with line breaks in it, which is exactly what makes it useful for working out what changed.

Is it safe to ship formatted output?

It works, and it is worth avoiding. Formatting is a modest information leak in its own right, because line and block boundaries restore some of the structure the packing removed, and the file is larger for no benefit to the user. Treat the formatted build as a diagnostic artifact you keep for the release rather than the artifact you publish, and rebuild without formatting for what you actually deploy.

What is the fastest way to map an output construct back to my source?

Turn on the line-number option alongside formatting. It appends original line-number hints where it can work them out, which turns the usual hunt through a rewritten file into opening the source at the line it names. Combined with indentation preservation, which keeps nesting depth visible, you get output you can read structurally rather than one long line you can only search.

How do I make sure the formatted build matches the one I shipped?

Pass a seed. Identifier generation is randomised per build by default, so a formatted rebuild would otherwise invent different names from the release you are trying to diagnose. With a fixed seed recorded alongside the release, the formatted and unformatted builds generate the same names, and a symbol you find in the readable copy is the same symbol in the shipped one. See <a href="ReproducibleBuilds.aspx">reproducible builds</a>.

Why is my output still packed when formatting is enabled?

Almost always because compression is also enabled. When the script is packed into a self-extracting wrapper, the formatted layout is not used, because what gets emitted is the wrapper rather than your laid-out code. Turn compression off for the diagnostic build, keep formatting on, and reproduce the problem against that artifact. See <a href="Compressor.aspx">the compressor</a>.

Which option name do I set, the alias or the raw one?

Either, and never both. Each has a config alias alongside the raw engine option, and setting the alias and the raw option together is the kind of ambiguity that produces a build you cannot explain later. Pick one convention for your project, write it in your build documentation, and keep the whole configuration in that style.

Try this in the online obfuscator

Paste your own code and see this option applied, or compare plans for larger projects and the desktop app.

Try It Free See Pricing