Take the 2-minute tour ×

I need to write a GUI related javascript library. It will give my website a bit of an edge (in terms of functionality I can offer) - up until my competitors play with it long enough to figure out how to write it by themselves (or finally hack the downloaded script). I can accept the fact that it will be emulated over time - thats par for the course (its part of business). I just want to have a few months breathing space where people go "Wow - how the f*** did they do that?" - which gives me a few months of free publicity and some momentum to move onto other things.

To be clear, I am not even concerned about hard core hackers who will still hack the source - thats a losing battle not worth fighting (and in any case I accept that my code is not "so precious"). However, what I cannot bear, is the idea of effectively, simply handing over all the hard work that would have gone into the library to my competitors, by using plain javascript that anyone can download and use. If someone is going to use what I have worked on, then I sure as hell don't want to simply hand it over to them - I want them to work hard at decoding it. If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order) - So, I'm not claiming that no one could have written this (which would be a preposterous claim in any case) - but rather, what I am saying is that no one (up to now) has made the functionality I am talking about, available to this particular industry - and I (thinking as an entrepreneur rather than a geek/coder), want to milk it for all its worth, while it lasts i.e until it (inevitably) gets hacked.

It is an established fact that not one website in the industry I am "attacking" has this functionality, so the value of such a library is undeniable and is not up for discussion (i.e. thats not what I'm asking here).

What I am seeking to find out are the pros and cons of obfuscating a javascript library, so that I can come to a final decision.

Two of my biggest concerns are debugging, and subtle errors that may be introduced by the obfuscator.

I would like to know:

  1. How can I manage those risks (being able to debug faulty code, ensuring/minimizing against obfuscation errors)

  2. Are there any good quality industry standard obfuscators you can recommend (preferably something you use yourself).

  3. What are your experiences of using obfuscated code in a production environment?

share|improve this question
This post deserves a golf clap. <golfclap/> –  Jonathan Feinberg May 19 '10 at 2:54
@Jonathan, you're usage of the <goldclap/> tag is worth a <golfclap/>. –  Anurag May 19 '10 at 3:48
@morpheous - you should read some of Paul Graham's essays, it'll give you a good appreciation of the mechanics of startups. –  CurtainDog May 19 '10 at 4:22
You are confusing reverse engineering for hacking and appear to not understand the value of a trade secret as a form of protected intellectual property. –  austin cheney May 19 '10 at 4:47
show 1 more comment

11 Answers

up vote 31 down vote accepted


So really, you're trying to solve a business issue with technical measures.

Anybody worth his salt as a Javascript programmer should be able to recreate whatever you do pretty easily by just looking at the product itself, no code needed. It's not like you're inventing some new magical thing never seen before, you're just putting pieces together in a new way, as you admit yourself. It's just Javascript.

Even if you obfuscate the script, it'll still run as-is, competitors could just take it and run with it. A few customizations shouldn't be too hard even with obfuscated code.

In your niche business, you'll probably notice pretty quickly if somebody "stole" your script. If that happens, it's a legal issue. If your competitors want to be in the clear legally, they'll have to rewrite the script from scratch anyway, which will automatically buy you some time.

If your competitors are not technically able to copy your product without outright stealing the code, it won't make a difference whether the code is in the clear or obfuscated.

share|improve this answer
+1 Ok, now we are getting warm. Someone is FINALLY reading my question and UNDERSTANDING where I'm coming from –  morpheous May 19 '10 at 4:02
@morpheous Being in the right place at the right time with the right idea and the right execution is a lot more important than possessing some secret sauce which needs to be kept hidden at all cost. Just look at Twitter, it's trivial to clone without looking at any code, yet that's where the party's at. –  deceze May 19 '10 at 4:28
"So really, you're trying to solve a business issue with technical measures." ... Isn't that the whole point of technology (from a business point of view) ? ;) "Being in the right place at the right time with the right idea and the right execution is a lot more important ..." - Ne'er a truer word been said. The point you make about Twitter is spot on, and does put things "a little into perspective". BTW, I dont have any "secret sauce" - and certainly my business is not relying on just the GUI ;). This is to be just another extra weapon in my toolkit (in the "arms race"). –  morpheous May 20 '10 at 6:30
@morpheous Then make sure to keep your weapons clean and not shoot yourself in the foot by obfuscating scripts in ways that'll leave you scratching your own head two months down the road. ;) –  deceze May 20 '10 at 7:04
Where as I agree totally that there is no need to hide for reasons of copying, I believe there is a need for reasons of security. Good coders does not necessarily make good crackers, it requires slightly different mindset. You can never predict what these people will try to do. And yes, if they are good, they can probably un-obfuscate, but why make it simple for them? If it is easy and non intrusive to add to you build process then do it. –  Ron Apr 16 '13 at 16:17
show 1 more comment

While you can go down the long, perilous road of obfuscators, you generally don't see them used on real, production applications for the simple reason that they don't really do much. You'll notice that Google apps, which is really a whole heap of proprietary and very valuable JavaScript when you get down to it, is only really minimized and not obfuscated, though the way minimizers work now, they are as good as obfuscated. You really need to know what you're doing to extract the meaning from them, but the determined ones will succeed.

The other problem is that obfuscated code must work, and if it works, people can just rip it wholesale, not understanding much of it, and use it as they see fit in that form. Sure, they can't modify it directly, but it isn't hard to layer on some patches that re-implement parts they don't like without having to get in too deep. That is simply the nature of JavaScript.

The reason Google and the like aren't suffering from a rash of cut-and-paste competitors is because the JavaScript is only part of the package. In order to have any degree of control over how and where these things are used, a large component needs to be server-based. The good news is you can leverage things like Node.js to make it fairly easy to split client and server code without having to re-implement parts in a completely different language.

What you might want to investigate is not so much obfuscating, but splitting up your application into parts that can be loaded on-demand from some kind of service, and as these parts can be highly inter-dependent and mostly non-functional without this core server, you can have a larger degree of control over when and where this library is used.

You can see elements of this in how Google is moving to a meta-library which simply serves as a loader for their other libraries. This is a step towards unifying the load calls for Google Apps, Google AdSense, Google Maps, Google Adwords and so forth.

If you wanted to be a little clever, you can be like Google Maps and add a poison pill your JavaScript libraries as they are served dynamically so that they only operate in a particular subdomain. This requires generating them on an as-needed basis, and while it can always be removed with sufficient expertise, it prevents wholesale copy-paste usage of your JavaScript files. To insert a clever call that validates document.href is not hard, and to find all these instances in an aggressively minimized file would be especially infuriating and probably not worth the effort.

share|improve this answer
+1 very useful and informative. Could you tell me a little bit more about this "poison pill" approach (I like, I like) - specifically, the bit of validating document.href. That + minify could be a working solution –  morpheous May 19 '10 at 5:40
Have a function that, through some misdirection, comes to verify that document.location.host is as expected. Obviously having the text "document.location.host == 'customer.com'" will be easy to find and remove, but you can achieve the same thing with some tactical obfuscation, e.g. a variable that refers to document, and some function that extracts location.host from it using a convoluted eval-based statement. If you implement several such checks in a variety of different ways and spike them into the library at several obvious and non-obvious locations, it will be hard for to remove them all. –  tadman May 19 '10 at 15:22
It is obviously easy to generate a script that will only "work" at the location it is loaded from if you manufacture it on the fly, and that's something easily done using something as simple as PHP. /js/library.js could actually be generated by /js/library.js.php if you configure your web server accordingly. If your library is sufficiently large and minified, finding the verification procedure will prove tricky without a lot of technical skill, and you've built in a significant barrier. Just make sure you verify your referral headers so they don't hyperlink your scripts! –  tadman May 19 '10 at 15:26
@tadman, Why did you say Google Maps used the poison pill approach? Did they really actually monitor the host and do rejections based on that? –  Pacerier May 2 at 15:59
Using the Google Maps JavaScript on a domain which they don't recognize triggers an error and prevents it from loading. You need to have a valid API key for it to properly engage, even though these keys are available for free. It enables Google to limit how their code is used. –  tadman May 2 at 16:05
add comment

Standard answer to obfuscation questions: http://stackoverflow.com/questions/29399/is-obfuscator-javascript-enough/29471#29471

IMO, it's a waste of time. If the competitors can understand your code in the clear (assuming it's anything over a few thousand lines...), they should have no trouble deobfuscating it.


Obfuscation will cause more bugs, you can manage them by spending the time to debug them. It's up to the person who wrote the obfuscation (be it you or someone else), ultimately it will just waste lots of time.


  1. Being completely bypassed by side channel attacks, replay attacks, etc.
  2. Bugs.
share|improve this answer
add comment

Javascript obfuscation facts:

  • No one can offer a 100% crack free javascript obfuscation. This means that with time and knowledge every obfuscation can be "undone".
  • Minify != obfuscation: When you minify your objective is: reduce code size. Minified code looks completly different and its much more complex to read (hint:jsbeautifier.com). Obfucation has a completly different objective: to protect the code. The transformations used try to protect Obfuscated code from debugging and eavesdropping. Obfuscation can even produce a even bigger version of the original code which is completely contrary to the objectives of minification.
  • Obfuscation != encryption - This one is obvious but its common mistake people make.
  • Obfuscation should make debugging much much harder, its one of it objectives. So if it is done correctly you can expect to loose a lot of time trying to debug obfuscated code.That said, if it is done correctly the introduction of new errors is a rare issue and you can easily find if it is an obfuscation error by temporarily replacing the code with non obfuscated code.
  • Obfuscation is NOT a waste of time - Its a tool. If used correctly you can make others waste lots of time ;)

Javascript obfuscation fiction: ( I will skip this section ;) )

Answer to Q2 - Sugested obfuscation tools:

  • For an extensive list of javascript obfuscator: malwareguru.org. My personal choice is jscrambler.com.

Answer to Q3 - experiences of using obfuscated code

  • To date no new bugs introduced by obfuscation
  • Much better client retention. They must come to the source to get the source;)
  • Occasional false positives reported by some anti-virus tools. Can be tested before deploying any new code using a tool like Virustotal.com
share|improve this answer
So you are saying in other languages there is actually 100% obfuscation? –  Pacerier May 2 at 16:13
add comment

Google's Closure Complier obfuscates your code after you finish writing it. That is, write your code, run it through the compiler, and publish the optimized (and obfuscated) js.

You do need to be careful if your using external js that interfaces with the lib though because it changes the names of your objects so you can't tell what is what.

share|improve this answer
If obfuscation is only a side effect of optimization, it will probably be trivial to deobfuscate. –  L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ May 19 '10 at 3:02
How is deobfuscation trivial? All your variable names are converted to 1 or 2 character cryptic names that cannot be converted back into something understandable by a human. –  austin cheney May 19 '10 at 3:40
Basic obfuscation is enough to prevent most prying eyes. –  Anurag May 19 '10 at 3:51
add comment

You could adopt an open-source business model and license your scripts with the GPL or Creative Commons BY-NC-ND or similar

share|improve this answer
That will not protect from disclosure of trade secrets, which I believe is the ops intent. –  austin cheney May 19 '10 at 3:41
The op stated that the secrets are going to to get out anyway. The trick is to not lose the fame and fortune of developing a great solution. Make is part of the license that the name of the company and link be included with all usage in an unobscured way. I guess the point here might be, there is a legal solution to this problem because the technology solutions so far have always failed. –  Gabriel May 19 '10 at 3:52
add comment

Automatic full-code obfuscation is so far only available in the Closure Compiler's Advanced mode.





share|improve this answer
add comment

While obfuscation in general is a bad thing, IMHO, with Javascript, the story is a little different. The idea is not to obfuscate the Javascript itself but to produce shorter code length (bandwidth is expensive, and that first-time users may just be pissed off waiting for your Javascript to load the first time). Initially called minification (with programs such as minify), it has evolved quite a bit and now a full compiler is available, such as YUI compiler and Google Closure Compiler. Such compiler performs static checking (which is a good thing, but only if you follow the rules of the compiler), minification (replace that long variable name with 'ab' for example), and many other optimization techniques. At the end, what you got is the best of both worlds, coding in non-compiled code, and deploying compiled (, minified, and obfuscated) code. Unfortunately, you would of course need to test it more extensively as well.

share|improve this answer
add comment

The truth is obfuscator or not, any programmer worth his salt could reproduce whatever it is you did in about as much time as it took you. If they stole what you did you could sue them. So bottom line from the business point of view is that you have, from the moment you publish, roughly the same amount of time it took you to implement your design until a competitor catches up. Period. That's all the head start you get. The rest is you innovating faster than your competitors and marketing it at least as well as they do.

share|improve this answer
add comment

In my opinion, the best way to obfuscate important javascript is by hand. The code can be made nearly unreadable, and the logic apparently illogical.

Here is a snippet of code I use in production every day. Every prototype, function, parameter and number is a series of varying length underscores. Yes, it really works, and it works really well.

function (____){var ______=__.___(___[_],______,"____"+___[_-_]+"_________"+__[_-_]);___[__.____("____")]=__.____(___[_-_],__.____(""),"");___[__._____("_______")]=//___
___[__._____("______")]);__________+=_;___[_-_]+="_";}return ___[__._____("_______")]+__.______(___[_-_]+___[__._____("____")],___[_-_],"_");}

It might be possible to create a tool to do this, but it would be pretty difficult, as the code has to be written from the beginning with obfuscation as one of the end goals.

share|improve this answer
Your script has error: Uncaught SyntaxError: Unexpected token ( –  Pacerier May 2 at 16:17
add comment

Write your web site in flash, or better yet in Silverlight. This will give your company unmatched GUI, that your competitors will be salivating about. But compiled nature of flash/dotnet will not allow them easily pick into your code. It's a win/win situation for you ;)

share|improve this answer
I loathe to think that anyone considers plugin based solutions a win in any scenario. –  Gabriel May 19 '10 at 3:49
@Longpoke There are features in Flash that aren't in HTML5, for example DRM (which is quite important to some). Don't pretend otherwise. Also, "forced to adopt"? I wish somebody would have told Microsoft before they released IE6. Nobody is being forced to adopt anything. Note that I do share the general anti-Flash sentiment, just keep it realistic, please. –  deceze May 19 '10 at 4:09
@Longpoke HTML5 is not yet a standard and nobody is forced to adopt it. If you believe a standard is equivocal to forced adoption then I do not believe you understand what a standard is, and definitely not understand passive standard bodies such as the W3C. Technology standards are not legal mandates. There is no evidence to suggest that HTML5 is replacing Flash. This merely suggests that you have an irrational preferential bias favoring HTML5. –  austin cheney May 19 '10 at 4:42
@austin cheney Because it begs the question: "to whom is your product a service". Not all users can or will install the plugins required to use the technologies you suggest. While they may be perfectly legitimate solutions for a new primed Windows PC the same is not likely to be the case on Linux/Mac/Or even legacy hardware Windows systems. If the OP wants to create a cross platform solution that utilizes all the bounty of the web he has to, by definition, avoid pigeon holed solution like Silverlight or Flash. –  Gabriel May 19 '10 at 5:14
@deceze @austin cheney: All browsers will adopt HTML5 to some extent when it becomes standardized. I never said to use any HTML5 to obfuscate, because obviously, it wont obfuscate any better than HTML4....... I highly doubt they'll leave out canvas, video, and audio.... There is no irrational bias in favoring HTML5, the only thing irrational is that people still use Flash. I don't horrible tack on poorly integrated poor security technologies in my browser. Serving a JavaScript library in Flash or Silverlight is what's irrational. –  L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ May 19 '10 at 12:53
show 6 more comments

Your Answer


