Source handling
Published
It depends on one thing that most people never check: whether your code leaves the page. A web form feels like a local tool, but if the protected output comes back from a server, then your source went to that server first. That is not automatically a problem — it is a decision, and it deserves ten seconds of attention rather than none.
Pasting is uploading
The mental model to fix first: a textarea is not a sandbox. When you paste a file into an online obfuscator and press the button, one of two things happens. Either the transformation runs in your browser in JavaScript, in which case nothing is transmitted, or the text is posted to a backend that does the work and returns the result. Both designs are legitimate. Only one of them involves your source code arriving on someone else’s disk.
Server-side processing is how every tool with a serious transform pipeline works, because the heavy analysis — whole-project member renaming, control-flow restructuring, bytecode virtualization — is not something you want to reimplement and ship to a browser tab. So the honest framing is not “uploads are bad”; it is “know which one you are using, and match it to the sensitivity of the file.”
The ten-second test
Open your browser’s developer tools, go to the Network tab, paste a two-line sample, and click obfuscate. Watch what happens:
- A request appears carrying your code — processing is server-side. Everything below about vendor questions applies.
- No request appears — the work happened in the page. Your code never left the tab.
Do this once per tool. It is faster than reading a privacy policy and it cannot be spun. Note that a tool can be server-side and still be perfectly appropriate for your use — you just want to know which conversation you are having.
Questions worth asking any hosted tool
If a tool processes your code on a server, these are the things a security reviewer will ask you, so ask them first:
- Who operates it? A named company with a registered address, terms of service, and a privacy policy is a different risk profile from an anonymous page carrying six ad networks.
- Is the transport encrypted? HTTPS end to end, no mixed content on the page doing the posting.
- What is retained, and for how long? The answer should be written down somewhere you can link to, not inferred.
- Is there an authenticated, automatable path? If the only interface is a public paste box, you cannot put it in CI without a human in the loop — which usually means someone will paste production code by hand at 6pm on a release day.
- What does the tool do with the page itself? Trackers and third-party scripts on an obfuscator page are worth a glance, given what you are about to type into it.
For JavaScript Obfuscator specifically, the workflow-by-workflow breakdown of what is transmitted lives in Security and Processing, and the operator details are on About and Privacy. The point is not that our answers are unique — it is that you should be able to find any vendor’s answers before you paste.
| If you are… |
Use |
Because |
| Evaluating a tool |
The online obfuscator, with a sample |
Fastest feedback; use throwaway code, not the crown jewels |
| Shipping releases repeatedly |
The npm CLI or a bundler plugin in CI |
Credentials from CI secrets, identical output every build, no manual pasting |
| Under a policy that forbids upload |
Desktop Local Standard mode |
Processes plain ES5 .js on the workstation; no API credentials needed |
| Answering a security reviewer |
Source-free evidence packets |
Manifests, hashes and reports satisfy review without shipping source anywhere |
The local option, stated honestly
If your policy says source cannot leave the machine, the WinUI 3 desktop app’s opt-in Local Standard mode processes plain ES5 .js files on the workstation using a bundled basic identifier-protection engine, with no API credentials involved. It is deliberately narrow: modern syntax, mixed-file extraction, the advanced option set, Runtime Defense, reports, and VM protection all run through the hosted workflow. If your input is outside that ES5 boundary, transpile first or use an approved local tool — that is a real boundary and pretending otherwise would waste your time during review.
The risk people actually get hit by
In practice, the leak that costs teams their source is almost never the obfuscator. It is the source map published next to the protected bundle. A .map file hands back original filenames, original identifiers, and often the original source text in full — no matter how strong the transforms were. Worth checking your own production origin for right now: request your main bundle’s .map URL and see whether it answers.
The second most common one is a secret in the bundle. Obfuscation raises the cost of reading code; it does not make an embedded credential private, because anything shipped to the browser is already public.
A workable policy
Use the online tool for what it is good at — evaluating, comparing, and understanding what a transform does to a snippet. Move to an authenticated pipeline the moment protection becomes part of a release, so credentials live in CI secrets and no human is pasting proprietary code into a browser. Keep source maps out of your protected artifacts. And when a reviewer asks what happens to your code, hand them a documented answer rather than a shrug.
Related reading