JavaScript Obfuscator

JavaScript Obfuscator

What the obfuscator does

This page takes JavaScript source and produces a minified, obfuscated version. It can run a Terser minification pass, then apply transforms such as control-flow flattening, dead-code injection, string-array encoding, base64 string encoding, self-defending output, console disabling and hexadecimal identifier names. The result is harder to read and usually smaller. It is not encryption, and it does not make the code impossible to reverse engineer. The page runs in the browser and lets you copy or download the output.

Minify versus obfuscate

Minification removes whitespace and shortens names while keeping the program's behaviour. Obfuscation goes further by changing the structure and the way strings and control flow appear. Minification is usually safe when the source is well behaved. Obfuscation is more aggressive and can break code that depends on function names, exact source text, reflection or browser debugging. Use the lightest setting that meets your goal, and always test the result.

The Terser stage

Terser is a JavaScript minifier. In this pipeline it can compress the code, mangle local names, drop console calls and remove debugger statements. Dropping console output is convenient for production, but it can hide diagnostics you still need. Mangling can break code that relies on function names or stack traces. If the project uses a bundler with its own minifier, compare the output and avoid minifying twice without testing.

The obfuscation stage

The obfuscator can flatten control flow, inject dead code, move strings into a lookup array, encode strings as base64, add self-defending checks and rename identifiers to hexadecimal names. These transforms make the source less approachable, but they also increase the chance of a runtime error. Self-defending output can behave badly if the code is modified or formatted later. Console disabling can remove logs that an error handler expects. Test each feature rather than enabling everything.

How to use it

Paste the JavaScript into the editor. Choose the options you need, or start with the default pipeline. Press the obfuscate button. The output appears in a second editor with size statistics. Copy the result or download it as protected.min.ob.js. Keep the original source in version control. The page does not save a project, remember settings or deploy the file. If the CDN libraries fail to load, the page may not be able to process the input.

Output and download

The output is a single JavaScript file. The download name is protected.min.ob.js, which reflects the default minify-and-obfuscate pipeline. The size statistics show the before-and-after size; a smaller file is not automatically faster, because some obfuscation transforms add runtime work. Copy the output into the build that will actually ship, or download it and compare it with the rest of the bundle. Do not replace the source file with the obfuscated output.

Test after obfuscation

Run the obfuscated file through the same tests, browser flows and error paths as the original. Check event handlers, dynamic imports, workers, service workers and code that uses function names or string reflection. Open the console and confirm that intended logging and error reporting still work. Test the production build, not only the pasted snippet. If something breaks, disable the most aggressive transform and try again.

Size and performance

Obfuscation can reduce file size, but it can also increase it when string arrays, decoder functions and dead code are added. Self-defending and control-flow transforms add runtime overhead. Measure the actual bundle size and startup time. A smaller file that throws an error is worse than a larger file that works. For a large application, use the project's build pipeline rather than pasting a bundle into a web page.

Security limits

Obfuscation is not encryption. The browser must execute the code, so the logic and any embedded secrets are still present in some form. A determined person can instrument the page, inspect network traffic and trace the code. Do not put API keys, passwords or private algorithms in client-side JavaScript and assume obfuscation protects them. Use a server-side API, short-lived tokens and proper access control for secrets.

CDN dependency

The page loads Terser and the obfuscator from external CDNs. If those requests are blocked by a corporate policy, an ad blocker or a network outage, the tools may not initialize and the page may leave you without a usable result. There is no offline fallback. For a repeatable build, install the libraries in your own project and run them from a script or a bundler.

Privacy and local processing

The JavaScript is processed in the browser and is not sent to Newisty by this page. The CDN libraries still load from external hosts, so those requests are visible to the providers. The code stays in the page until you clear it or close the tab. Do not paste proprietary source on a shared device. Download the output and clear the editors when you finish.

Common problems

If the output is empty, the libraries may not have loaded or the input may not be valid JavaScript. If the obfuscated code throws an error, disable control-flow flattening, self-defending output or console disabling and test again. If the file is larger, the string array or dead-code transform may be adding overhead. If a function name is missing, mangling or renaming changed it. If the page is slow, use a smaller input.

When to use it

Use it for a small script where you want a less readable production file, or to demonstrate why obfuscation is not a security boundary. It is also useful for a quick size comparison before setting up a real build pipeline. For a serious application, use a bundler with a tested minifier, keep source maps private and protect secrets on the server. Obfuscation can be one layer, not the foundation.

What not to do

Do not treat obfuscation as encryption. Do not hide API keys or passwords in client code. Do not enable every transform without testing. Do not overwrite the original source. Do not assume a smaller file is faster. Do not rely on a CDN for a production build. Do not paste proprietary code on a shared device. Do not ship obfuscated code without running the test suite.

Frequently Asked Questions