Web Security Application Security

JavaScript and HTML5 Protection Questions

October 13th, 2014 | By Filipe Silva | 3 min read

We identified frequently asked questions about Javascript and HTML5 protection from Jscrambler's users and clients. In this article, we have collected the most common and interesting ones. What are some of the concerns with JavaScript, HTML5, and security?

Today, we are going to give answers to the following three questions:

  1. How can I reach the maximum level of protection?

  2. Do you also provide non-alphanumeric obfuscation?

  3. Do you have something that cannot be reverse-engineered?

How can I reach the maximum level of protection?

Our maximum level of protection is available on some of Jscrambler's client-side security Tier plans. If you are doing something with HTML5, you’d be interested to know that we support protecting it, including Canvas code.

These plans also include the Self-defending transformation, which is a combination of anti-tampering and anti-debugging. With the former, your code will be able to detect changes and break down intentionally, and the latter causes your code to break if debugging activities (e.g., popping up the Chrome Dev Console) are detected.

Regarding what protection to use, default templates such as “Obfuscation”, “Domain Lock”, or “Self-Defending” are solid, working out-of-the-box options to get your code protected.

Further protecting your code works best if you have good knowledge of the original code. Are you trying to hide an algorithm? Prevent tampering? Hiding secrets?

Depending on your answers, different transformations might be useful. With premium accounts, you can go to the Advanced Users tab and select the transformations individually that work best for your code.

Last but not least, you can use the Ignore Code Blocks feature to substantially increase the protection in specific parts of your code without growing it too much or making it slower.

Do you also provide non-alphanumeric obfuscation?

No, we do not provide non-alphanumeric obfuscation, but we understand why you’re asking.

Non-alphanumeric obfuscation is a visual nightmare. Also, at first sight, it looks like something really hard to revert. However, the problem with full non-alphanumeric obfuscation is that the resulting code size is insane.

Non-alphanumeric obfuscation example

As an example, something like ‘console.log(1)’ that has 15 bytes would end up as ~2500 bytes of non-alphanumeric code. If we applied this to ordinary JavaScript, the resulting size would be unbearable (see figure below). If that wasn’t enough, it is also rather easy to write a tool to automatically reverse this to its original form.


Do you have something that cannot be reverse-engineered?

Everything can be reverse-engineered. So far, the only thing that comes to mind that has not been reverse-engineered is the human brain. No solution can promise 100% protection.

That being said, our solution goes higher and deeper in providing you with protection. It sets the difficulty level so high that only a few percent of JS hackers will be able to reverse it, and of those, even fewer will be motivated to do it.

With the rise of artificial intelligence, would you say that Chat GPT would be able to reverse engineer Jscrambler obfuscation? We give all the answers in our blog post about our tests with ChatGPT-4.

The Jscrambler solution is hard to reverse engineer. Why?

Jscrambler has more and better obfuscation techniques, but contrary to other solutions, it goes beyond them. It leverages obfuscation to install code traps scattered throughout the code that will provide you with extra levels of protection:

  • Licensing enforcement capabilities: Domain Lock, Browser/OS Lock, Expiration date

  • Self-defense: Anti-tampering and Anti-debugging

Keep visiting us because we’ll be covering other questions we come across, and don’t forget to send us your questions, issues, and suggestions.

Download our free data sheet on JavaScript Security Threats, which provides an overview of the most relevant attacks and how to prevent them.


The leader in client-side Web security. With Jscrambler, JavaScript applications become self-defensive and capable of detecting and blocking client-side attacks like Magecart.

View All Articles

Must read next

Javascript Web Security

Self-Defending Capabilities Available in HTML5/JavaScript Applications

For the first time Self-defending capabilities are available in HTML5/JavaScript applications.

March 14, 2014 | By Jscrambler | 2 min read


HTML5 Just Turned 18

HTML5 to finally get the standard specification complete and released, as confirmed by W3C a week ago. What's in it for us?

November 5, 2014 | By José Magalhães | 3 min read

Section Divider

Subscribe to Our Newsletter