This page collects the smaller options that do not need their own full article but still matter when you are building a final protection profile. Each one is listed with the API parameter it maps to and the plan tier it needs, so you can tell at a glance whether a profile you are copying will run on your account.
Keep Header Comment
Plan: Free. Keeps the first comment block from the source file at the start of the output. Protection normally strips comments, which is usually what you want — but a licence header is a legal artifact, not a comment, and several open-source licences require it to travel with the code.
Use it whenever your bundle includes third-party code under a licence with an attribution clause. If your bundler already concatenates several licence headers into one banner, that banner is the first comment block and this option preserves it intact.
JS Header Text
Plan: Free. Inserts custom text at the beginning of every output file. Teams use it for ownership notices, a copyright line, a support URL, or build metadata such as a version tag and a build date.
Two practical notes. First, this text is not protected — it is a comment, and anyone can read or delete it, so treat it as a notice rather than a control. If you need a marker that can be verified rather than merely read, use a signed watermark instead. Second, keep it short: the header is repeated in every emitted file, so a long banner across many chunks is real bytes on every request.
Lock Domain / Date / Browser / OS
API params: LockDomain + LockDomainList + LockDomainMsg, LockDate + LockDateValue, LockStartDate + LockStartDateValue, LockBrowser + LockBrowserList, LockOS + LockOSList. Plan: Basic and up.
These add runtime guards so protected code only executes in an approved environment or within an approved window. If a condition fails, the original logic does not run and the configured message is shown instead. Date values use YYYYMMDD; domain lists are newline-separated and checked against the page host.
Be clear-eyed about what this is for. A lock is a licensing control, not a security boundary: the check runs on the attacker’s machine, so a determined reader can find and remove it. What it does well is stop casual redistribution — a licensed widget copied onto a second domain simply stops working, and a trial build stops working when the trial ends. Combine a lock with obfuscation so the check is expensive to find, and with a beacon so removal attempts are visible to you rather than silent.
The browser and OS guards cross-check User-Agent Client Hints against legacy User-Agent and platform signals where both are available, and route contradictions through your configured runtime-defense action. An attacker can still align every browser-visible signal, so treat these as policy controls rather than a hardware trust boundary. For session locks, fingerprint allow-lists, signed release envelopes, debugger checks, callbacks and beacon alerts, see Runtime Defense.
Dead Code Insertion
API params: AddDeadCode, DeadcodeLevel. Plan: Corporate and up.
Injects statements that never execute between the ones that do. The point is not to confuse a runtime — it is to defeat pattern-matching by a human or a script reading the output, because the shape of a recognisable routine is no longer contiguous or recognisable.
This is the option with the clearest size cost in the set, and DeadcodeLevel is where you spend it. A low level on a large bundle is usually the right default; a high level belongs on the one module that matters, not on everything. Note that dead code is also the transform most visibly affected by compression — injected statements compress well, so the increase in transfer size is much smaller than the increase in raw size. Measure both before deciding, and see the bundle-size measurements for what to expect.
Mixed Server Code
API param: MixedServer. Plan: Enterprise.
Targets files that are not pure JavaScript — an .aspx, .php, .jsp or .html page with script blocks and server tags interleaved. Without this option the protector sees one file of unparseable text. With it, the script regions are located and protected while everything around them is left byte-identical.
These files are genuinely more fragile than standalone JavaScript, for a reason worth understanding: a server tag can appear inside a JavaScript expression, as in var limit = <%= MaxRows %>;. That is not valid JavaScript until the server has rendered it, so the protector must treat the tag as an opaque token and preserve it exactly. Two rules follow. Do not let a server tag straddle a statement boundary, and always smoke-test a rendered page rather than the template, because the template is not what runs.
If your build can emit plain .js files instead, prefer that path — it is simpler and every other option composes with it more predictably.
Where these sit relative to the main transforms
None of the options on this page change how your logic is expressed; they add material around it, gate when it runs, or widen what kinds of file can be processed. The transforms that actually rewrite your code — renaming, string handling, control flow and virtualisation — each have their own page, and the obfuscation glossary defines every term in one place if you are still mapping vocabulary between vendors.
Frequently asked questions
Which of these options are licensing controls rather than security boundaries?
The domain, date, browser and operating system locks, and the distinction matters. The check runs on the reader's own machine, so somebody determined can find and remove it. What a lock does well is stop casual redistribution: a licensed widget copied onto a second domain simply stops working, and a trial build stops working when the trial ends. Combine a lock with obfuscation so the check is expensive to find, and with a beacon so removal attempts are visible rather than silent.
How do we keep a licence header in the output when comments are stripped?
Use the keep header comment option, which preserves the first comment block from the source file at the start of the output. Protection normally strips comments, which is usually what you want, but a licence header is a legal artifact rather than a comment and several open-source licences require it to travel with the code. If your bundler already concatenates several licence headers into one banner, that banner is the first comment block and the option preserves it intact.
Is the custom header text protected in any way?
No, and it should be treated as a notice rather than a control. The header text is inserted as a comment, so anyone can read it or delete it. If you need a marker that can be verified rather than merely read, use a signed watermark instead. Keep the text short as well, because it is repeated in every emitted file and a long banner across many chunks is real bytes on every request.
How much does dead code insertion cost in file size?
It has the clearest size cost of any option in this group, and the level setting is where you control it. A low level across a large bundle is usually the right default, while a high level belongs on the one module that matters rather than on everything. Injected statements also compress well, so the increase in transfer size is much smaller than the increase in raw size, and both are worth measuring before deciding.
What does mixed server code support actually do?
It locates and protects the script regions inside files that are not pure JavaScript, such as pages with script blocks and server tags interleaved, leaving everything around them byte-identical. Without it the protector sees one file of unparseable text. These files are genuinely more fragile, because a server tag can appear inside a JavaScript expression and is not valid JavaScript until the server has rendered it, so the tag has to be preserved as an opaque token.
What are the rules for working safely with mixed server files?
Do not let a server tag straddle a statement boundary, and always smoke-test a rendered page rather than the template, because the template is not what runs. If your build can emit plain JavaScript files instead, prefer that path: it is simpler and every other option composes with it more predictably.