DomainLock

I created DomainLockJS to fight code theft. As of 2025, DomainLock scripts have been generated for 16000+ licensable software assets. DomainLockJS uses a novel approach to throw hard-to-trace errors on non-authed domains via encrypted payloads.

Can you really protect client side Javascript?

Short answer: No. But sorta.

I originally created DomainLock as a quick, weekend project because I needed to protect licensable Javascript assets against rampant code theft.

At the time I thought maybe a couple other devs would find the script useful. Not long afterwards, it became clear that thousands of other devs had the same issue, and were all seeking an answer to the same universal problem: Javascript code is eminently steal-able.

Within a year of launch, DomainLock’s generated encrypted snippets started to appear bundled with hundreds of licensed javascript products and on thousands of websites across the web. Founders and developers wanted their code protected. More importantly, they wanted a way to safely license their IP on a per-website basis without their code being used on unauthorized, non-paying websites.

The trouble with Javascript

I love Javascript. I don’t consider myself a real coder (real coders put my skills to shame), but as a lifelong web creative and as a founder, I’ve spent thousands of hours wrangling Javascript code. Client-side Javascript is versatile. It’s easy. It’s native. It’s mostly logical (except for the weird parts). And It’s used on 99% of all websites, which can’t be said of any other programming language.

But Javascript is also also incredibly easy to steal.

That last bit can be frustrating for founders: We live in a world of third-party libraries, intellectual property and software licensing, and yet the code we invest countless hours on can literally be copy-pasted into a text editor and used wherever, however anyone likes — not legally of course, but it happens all the time.

Can client side Javascript be 100% safeguarded?

Nope. Never. Not if it doesn’t have server-side dependencies. Code that lives on a server can be sufficiently black-boxed and authenticated. But purely client-side code lives in its entirety, in publicly accessible areas. And there’s the rub. No matter how hard we try to safeguard our code, we’ll never actually end up with true protection. This is an especially serious problem for libraries intended to live natively on third-party servers, unless the code “phones home” to authenticate and to validate licensing.

Locking Javascript to a domain

There’s never going to be a way to truly copy-protect client-side Javascript. But that doesn’t mean we can’t make it frustratingly difficult to steal.

The idea behind DomainLock JS was to make code theft annoyingly difficult by locking licensed code to the licensee’s URL. While there’s no such thing as a client-side domain locking that can’t be circumvented — we can lay down some speed bumps which prevent a fast getaway. DomainLock allows developers of licensable assets to rapidly deploy unique, encrypted, domain-specific snippets within their codebases.

This is extremely useful for anyone who distributes commercial code to client websites. Most would-be thieves will simply attempt to drop the same package into another codebase, on another website and see if it works. When it doesn’t, most will give up rather than embark on a long process of bug hunting.

As I wrote on dev.to when the project first launched, I it’s a trivial coding task to check a user’s domain and stop execution of the code. However, that simplistic approach wouldn’t represent much of a deterrent. Why? Because:

1. The code could be read and searched for the domain name. (DomainLock’s code doesn’t include an easy to find reference to the domain name — even when decrypted.)

2. A simple trace can tell a potential code thief where the errors happened — allowing easy de-activation of the locking mechanism.

DomainLock’s script generator prevents those obvious countermeasures with an easy, single-click script generator.

Slowing them down

It’s #2 above is where DomainLock shines. DomainLock creates hard-to-trace errors, in unrelated functions via an encrypted payload, hidden at random in a codebase — making debugging more difficult.

DomainLock is a simple tool that allows anyone selling software licenses to quickly and easily create an obfuscated code snippet which can be hidden in any part of your codebase. By throwing hard to trace errors it creates an additional layer of copying deterrence for your code — which means increased licensing revenues.

Can it be circumvented? Yes. Any purely client-side code can be circumvented by any skilled, determined, would-be thief.

But that’s a tiny fraction of would-be thieves. And that’s the point.