Profiles

A profile is a starting point. Set it with options.profile and it switches on a consistent set of protections; anything you write explicitly in options still wins, including false.

{
  "options": {
    "profile": "High",
    "crasher": false
  }
}

Here the High profile applies, except for crasher, which stays off.

The five profiles

Each profile includes everything from the one above it.

Profile	Adds	Suited to
Ghost	Renaming (Alphabet, randomised), member shuffling, line numbers, local variables and parameter names removed.	Minimum overhead: names and metadata are gone, the logic is untouched.
Low	Light constant masking, Fast string encryption, source file names removed.	Libraries, and code where runtime cost matters most.
Medium	Reference obfuscation through invokedynamic, per-class salt, flow-based constant masking.	A solid default for applications.
High	Integrity checks, anti-tamper, loop-aware control-flow flattening with state masking, block shuffling, goto obfuscation, block breaks, fake exception edges, decompiler crashers, ghost members.	Production builds that ship to users.
Extreme	Heavy opaque predicates, flattening of loop bodies, aggressive overloading, intense ghost members, invoke dispatchers, method handle indirection, SPECK number encryption, integer tables, phantom annotations, static field initialisation, comparison obfuscation, field proxies, field descriptor mutation, method salt, Balanced string encryption.	Maximum protection, with the largest output and the highest CPU cost.

Choosing one

• Start with Medium, run your tests, then move up.
• Move to High for code you ship to users, once reflection and serialization are covered by annotations or exclusions.
• Keep Extreme for the code that matters most, and set a maxOutputRatio budget so heavy passes stop before the jar grows too much.
• If a protection hurts a hot path, keep the profile and turn that one option off, or exclude the method from that transformer.

Without a profile, only the options you write are applied.