Paste a JavaScript snippet, click Scan, see which patterns are likely to break under Maximum-mode obfuscation. This browser preview uses the same regex rule engine the server-side /v1/ai/compat-check.ashx endpoint uses when no live provider key is configured (eight categories: dynamic-eval, reflective property access, framework runtime, explicit-keep pragmas, inline HTML, source-map references, debug-leak). Accounts with a saved OpenAI or Claude key can call the API for provider-backed context review.
Local preview. The rules below are the same ones the API uses as its no-key and provider-failure fallback. The provider-backed version reasons about
which patterns are actually risky in your code's context — the rule-based version flags
eval as a finding regardless of whether the surrounding code makes it safe.
Add your AI key or
compare managed AI plans.
Paste JavaScript
Findings
no scan yet
Click Scan to see the report.
What the rule engine catches today
| Category | Severity | What it flags |
dynamic-eval | error | eval(...), new Function(...). Will not survive renaming if the evaluated string references locals. |
reflective | warning | Dynamic property access by string concatenation. Add to MemberExclusion. |
framework-rt | warning | Webpack symbols (__webpack_require__), React class lifecycle, Vue hooks. Add to VariableExclusion or exclude the file. |
explicit-keep | info | Pragma comments (// jso-keep, // @jso-keep). Confirm the matching exclusion entry exists. |
inline-html | warning | document.write, .innerHTML = . Template-string contents may reference renamed identifiers. |
source-map | warning | //# sourceMappingURL=. Shipping a source map alongside protected code undoes the protection. |
debug-leak | info / error | console.log (info) and debugger; (error). The latter halts under DevTools. |
How provider-backed review improves on this
- Context-aware
eval verdicts. A static dispatch table looks like eval but is actually safe. The rule-based version flags both equally; the LLM reasons about whether the evaluated string references locals that get renamed.
- Framework version inference. Today
componentDidMount is always flagged as a React lifecycle method. The LLM reads imports / decorators / surrounding patterns and can tell whether it's a class component (where the name must be preserved) vs a method-named-after-a-lifecycle-method-but-not-in-a-class (where it doesn't matter).
- Bundle-wide cross-referencing. When the customer passes multiple files (Phase 2), the LLM can correlate — "you have
eval(name + '()') at line 12 of a.js and function calculateLicenseHash in b.js; if those are linked, the rename will break the eval."
Frequently asked questions
What does the browser preview scan for?
Patterns in your code that are likely to behave differently once the aggressive transforms are applied. It is a regular-expression rule engine, the same rule set the hosted checker starts from, and it flags constructs whose meaning depends on names or on text that a transform will change. Think of it as a first pass that tells you where to look rather than a verdict on the file.
Does my code leave the browser when I scan it?
No. The preview runs entirely in the page, which is deliberate: pasting a snippet into a checker should not be a decision about data handling. That constraint is also why the preview is rule-based rather than provider-backed, since reasoning about the code requires sending it somewhere.
Why does the rule engine flag code that turns out to be fine?
Because pattern matching has no context. A static dispatch table can look exactly like dynamic evaluation to a regular expression, and a method name that belongs to a framework lifecycle in one file is an ordinary method in another. The engine takes the cautious reading, which produces findings you can dismiss. Reviewing a short list of cautious findings is a good trade against missing a real one.
How does provider-backed review improve on this?
By reading the surrounding code instead of the line alone. It can tell a safe dispatch table from genuine dynamic evaluation, infer which framework and version a file belongs to before deciding whether a lifecycle name matters, and correlate across multiple files so that a call in one and a definition in another are considered together. Those are the three places a rule engine structurally cannot reach.
What should I do with a finding?
Decide whether the name or literal it points at crosses a boundary. If something outside the protected code depends on it, add it to your exclusions so it is preserved. If nothing does, the finding is noise and you can move on. Where a whole file is full of such constructs, protecting that file with a reduced option set is often better than maintaining a long exclusion list for it.
How much does a clean scan tell me about whether the build will work?
It tells you the known patterns are absent, which is useful and is not the same as the build being correct. The scan reads your source, and the things that break protected builds most often involve references from outside it, which no scan of one file can see. Treat a clean result as permission to proceed to the real test, which is running your end-to-end suite against the protected artifact.