If I write a client-side Javascript app (with a little bit of server interaction), how can I prevent people from copying the Javascript files to their own site? Should I, at all?

14 Answers 14


Should you care? No.

Why? Because there's nothing you can really do about it.

Some have predictably suggested obfuscation. This works for Java and .Net but Python, Javascript and Perl are all plain text so there's very little you can really do. The value in your site is undoubtedly the server side so don't worry about the Javascript.

  • 1
    If I can figure out what I need to know from disassembled (allegedly) obfuscated Java, I think I can manage Javascript and I'm hardly an expert at such "hacking" or reverse engineering. "Information yearns to be free" (quote I heard somewhere).
    – cletus
    Jan 31, 2009 at 13:31
  • 2
    Javascript has an innate defense: its tied to serverside code, which is inaccessible. Obfuscation is a placebo. It also makes it more difficult to diagnose error reports that you get. If someone is going to rip you off (and I think you're overstating the value of your JS code) you can't do much
    – cletus
    Jan 31, 2009 at 15:07
  • 1
    And what was the cool trick in question?
    – cletus
    Jan 31, 2009 at 15:11
  • 2
    The down votes make me laugh. Javascript is best used as a utility to enhance your site. The only code worth protecting is code that exposes information about the inner workings of your site and your company. Neither of these things belong in client script to begin with!
    – Jim Petkus
    Jan 31, 2009 at 17:14
  • 1
    @Jim: don't I know it. I think the count is currently 17 upvotes, 8 downvotes and due to being at the daily rep cap my rep from this answer is... -16.
    – cletus
    Jan 31, 2009 at 21:49

The best you can do is obfuscate the code so that others will have a hard time modifying it. Of course, you keep a copy of the original.

As a bonus, obfuscated code should be smaller and therefore quicker to load.

  • That's called Javascript minimization, isn't it? Jan 31, 2009 at 16:44
  • 4
    minification actually Feb 1, 2009 at 23:05

Why do you worry? I see two reasons it could be: 1) You are writing a commercial JavaScript library. Solution: Get another business plan, JavaScript libs tend to be free. Perhaps you can make money in a small niche of enterprises, but they are most likely not going to use illegaly copied code anyway.

2) You worry that your competitor is going to copy your site. If they do, you can rest assured that you will always be one step ahead of them. More likely, they are going to write their own code and copy the appearance and behavior of your site and nothing can save you from that except for getting stupid software patents, e.g. amazon one-click shopping.

IOW, don't worry. Put a copyright notice asking people to tell you if they use your stuff. If enough people do it, use the fact that you have created a useful library to get credit among geeks, which probably will be beneficial in the long run.

  • It's a web application, not a library :). Thanks for #2.
    – sjmulder
    Jan 31, 2009 at 15:01

No. Do not try and "protect" a client-side scripting language. Obfuscation doesn't work. Minifying has its uses (but anti-piracy is not one of them)

I would also recommend against minifying your code unless you get thousands of hits per day, where a few extra kilobytes per request will be a noticeable difference (and only do that once you compress all the images you're using correctly, which will save you far more than a few KB, setup caching properly and so on)..

Even if you minify/obfuscate the Javascript, people can still quite trivially copy it to their own site. It'll be a bit more difficult to modify, but depending on what the script does, that may not matter. For example, the WMD Editor people have mentioned is supplied, for public use, minified.

Obfuscation and minification can be similar, but if you were to properly obfuscate the code, you would have to basically rewrite large segments of it to make it difficult to understand.. This makes the code more complicated, and far harder to deal with (for you), so will introduce bugs.. If your Javascript becomes buggy, that will prevent piracy, since no one will want to use (or steal) it.. but, err, that's not good.

One of the great things about Javascript is anyone can right-click/view-source and learn Javascript by looking at live, working code.. If you are worried about people looking at the code, and copying it, the web/Javascript isn't the right language..

I would recommend putting a comment at the start of all your .js files and <script> blocks, with your information (name, website), and a license of some kind. Depending on what the code is, perhaps putting a notice saying "If you use all or part of this code in a project, please let me know about it!" may be far more effective than "Do not use this code for any other purpose, ever!"


You could obfuscate (or at least minify) the code to discourage this (although it's not unstoppable for someone who has the time. For example, the StackOverflow's deobfuscation of the WMD editor (but this was for a good reason!)).

Really any code you put frontend is going to be public and available for all to see/use.

  • WMD editor wasn't obfuscated, it was just minified.
    – lubos hasko
    Jan 31, 2009 at 13:16
  • Minifying JavaScript has the nice side affect of obfuscating it as well... var va = fa(); is as well as obfuscated.
    – Unkwntech
    Jan 31, 2009 at 13:17

Why worry about it at all? If your scripts are worth stealing you could instead make them open source and get help in honing them.

  • Beyond that you also potentially get credit and good PR for them. If you can't make these things work for you in a conventional business sense, look at how you can make them work for you in other ways. Jan 19, 2011 at 10:56

You can't really since it's an interpreted language that is always delivered in source code form. Even obfuscation is not going to help much if the pirate is motivated enough.

(Case-Example: The StackOverflow WMD Editor, which could be - stricly speaking - be seen as Piracy, although I know that Jeff and Dana only had good intentions)


No. You should not worry at all.

If your business is dependent on the secrecy of your JavaScript code, there is some serious problem with it.

Otherwise, just don't bother. May be you should try minimizing your JavaScript code to make pages load faster.


I use GWT (the Google Web Toolkit) for writing web applications, in which the code is all written in Java and can be debugged and tested with Java-centric tools, but is converted into JavaScript for release.

When not in PRETTY or DETAILED mode, the JavaScript generated by GWT is very highly optimized and obfuscated, making it extremely impractical to reverse-engineer. (A traditional JavaScript obfuscator will provide a portion of these benefits -- but not where the optimizations are dependent on GWT's ability to do detailed branch pruning and code-path analysis).

That said, in general, I'm -1 on obfuscation -- it means, for instance, that legitimate customers are less able to help you figure out their problems, even when they happen to have development skills and a copy of FireBug. You're the original author -- you know the code better than anyone else, and that gives you a competitive advantage over someone who's trying to run a cheap knockoff; further, if any such competitor is actually making real money off something they stole without permission, that opens them up having that money (or, potentially, treble the sum) taken away in a lawsuit; legitimate and serious competition won't go that route, and why worry about the other kind?


We use a lot of Javascript (and a lot of server-side) code for our web application, and we chose to "obfuscate" the Javascripts be removing any white-spaces, line breaks etc. - this will not really protect your code, but make it very very hard to read & understand, and most likely others will not bother due to the effort involved.

The reason we do this, however, is not so much that we do not want anyone to copy parts of our code, but rather to discourage our partners/customers to whom we deliver the code from making modifications directly in "our files" (to avoid troubles when the next update is installed)...

Note: Obfuscation has one disadvantage you should be aware of, though: if you ever need to debug that script code, you yourself will not be able to work with the obfuscated infromation, so this will always involve copying the 'readable' file to the server first.

  • 2
    I wouldn't call formatting Javascript in an editor or using some form of "pretty printer" to be a lot of effort. Reducing those things can be useful for reducing bandwidth (ie minify) but that's all.
    – cletus
    Jan 31, 2009 at 12:02
  • If the Javascript file is large, it is a lot of effort. Also, "pretty printers" don't work well (or don't work at all) on the "one single line contains all code" type of files.
    – ISW
    Jan 31, 2009 at 12:04

Going on the assumption that any sufficiently good javascript will get picked up by others, how about just swimming with the current and making the most of it?

Slap a license on it which permits use while requiring for example attribution. Maybe with a non-commercial clause like some Creative Commons variants too, if you really must.


Most of your application logic should be server-side. Javascript should only handle GUI stuff and simple interactions with the server. If your Javascript code contains enough application logic that you're worried about somebody stealing it, then you're probably doing something wrong.


If you have trade secrets, you can move the most sensitive parts of the code to ActionScript (Flash). It's essentially the same language as JavaScript, and it's stored in tokenized form.


If you are worried about determined hardcore hackers stealing your code, sorry, there is nothing you can do. But there are ways to make it inconvenient for casual thiefs. An relatively easy way to do it is to load some parts using XMLHttpRequest and eval() them; this could be disguised as (or included in) something that gets JSON data and uses them to populate the page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.