Code Watermarking

Code watermarking is a software protection technique that embeds a hidden, verifiable identifier, such as an owner, license, or build ID, into an application’s code without changing how it runs. If someone copies, leaks, or redistributes the code, the watermark lets the owner prove authorship and trace the copy back to its source.

Key facts

  • First formal model: Christian Collberg and Clark Thomborson set out a taxonomy and formal model of software watermarking, and introduced dynamic watermarks, in Software Watermarking: Models and Dynamic Embeddings (ACM POPL, January 1999). Earlier U.S. patents on the idea already existed.
  • Main types: Static watermarks, stored in the code itself, and dynamic watermarks, built in memory while the program runs.
  • What it protects against: Intellectual property theft, code cloning, unauthorized redistribution, and anonymous leaks.
  • What it doesn’t do: It doesn’t stop anyone from copying the code. It provides evidence after the fact, so it is paired with obfuscation and anti-tampering.
  • Newest frontier: Watermarking code generated by large language models (LLMs), for example, the SWEET method (ACL 2024).

How Code Watermarking Works

A watermark is a secret message hidden inside a program in a form only its owner can find. Every watermarking system follows the same lifecycle:

  1. Encode the identifier. The owner chooses what the mark should say, for example, “this code belongs to Organization X, protected on date Y,” and encodes it, often with a secret key.
  2. Embed it in the code. The mark is woven into the program’s structure, data, or runtime behavior. The application’s output remains unchanged.
  3. Ship the application. The watermarked code is deployed to browsers, devices, or customers like any other build.
  4. Recognize it later. When a suspicious copy appears, the owner runs a recognizer with the secret key to extract the mark.
  5. Verify ownership. A recovered mark shows the copy came from the owner’s codebase. With per-copy marks, it also shows which build or recipient the copy came from.

Collberg and Thomborson listed the properties a good software watermark needs. It must survive code transformations such as optimization, translation, and obfuscation. It must be stealthy and carry enough data. It must not slow the program down. And its presence must be provably deliberate, not a coincidence.

These requirements are harder to meet for web applications than for most software. Application logic runs in the browser, so anyone can download it, and minification or bundling alone strips simple markers such as comments.

Types of Code Watermarking

Watermarks are classified by where the mark lives and what it is meant to prove.

Static Watermarking

A static watermark is stored in the code itself: in identifier names, constant values, the order of independent statements, or the shape of the control flow. You can detect it without running the program. Static marks are easy to embed but easy to destroy because an attacker can rename, reorder, or rewrite code without changing what it does.

Dynamic Watermarking

A dynamic watermark doesn’t exist in the code at rest. It is built in memory while the program runs, usually when the program receives a specific secret input. Collberg and Thomborson’s 1999 paper introduced this approach, storing the mark in the structure of data on the heap. Dynamic marks survive many transformations that break static ones. A Purdue University implementation found the cost to be moderate increases in code size, execution time, and memory use.

Fingerprinting

Fingerprinting embeds a different mark in every copy: per customer, partner, build, or environment. A recovered fingerprint shows not just who owns the code but which distributed copy leaked.

Robust vs Fragile Watermarks

A robust watermark is designed to survive modification, so it can prove ownership even after an attacker changes the code. A fragile watermark is designed to break when the code is modified, which makes it useful as a tamper-detection signal.

Watermarking AI-Generated Code

A newer branch marks code produced by LLMs, so organizations can tell machine-written code from human-written code. Methods such as SWEET bias the model’s token choices during generation and detect them statistically. Code is harder to watermark than prose, because syntax fixes many tokens and any change can break execution.

Code Watermarking vs Code Obfuscation vs Code Signing

These three are often confused because they answer different questions. Obfuscation asks “can you understand it?”, signing asks “is it the version I shipped?”, and watermarking asks “whose is it, and where did it come from?”

Main goalProve ownership and trace leaksMake code hard to read and reverse engineerProve who published a file and that it hasn’t changed
Stops copyingNo. It provides evidence after the factNo, but it slows understanding and reuseNo
Proves ownershipYes, through a hidden markNoOnly while the signature stays attached
Survives when the code is copiedYes, if the mark is robustYes. The transformations stay in the copyNo. The signature is separate and easily dropped
Visible to usersNoCode looks scrambled; behavior is unchangedShown as a certificate or verification result
Typical useIP disputes, leak attribution, licensingProtecting business logic in the browser or appSoftware distribution and update integrity

In practice, the three complement each other. Obfuscation makes a watermark harder to find and remove, and the watermark proves ownership even if protected code is stolen.

Why Code Watermarking Matters

Client-side application logic is shipped to every visitor’s browser. Anyone can download, study, and reuse pricing rules, fraud checks, licensing controls, and proprietary algorithms. Without a watermark, an organization that finds its code in a competitor’s product, a pirated app, or a public repository has little technical evidence that the code is theirs.

Watermarking addresses several concrete risks:

  • IP theft and cloning. Competitors or fraudsters lift front-end logic and reuse it in their own products.
  • Anonymous leaks. Code shared with contractors, partners, or customers ends up somewhere it shouldn’t, with no way to tell which copy leaked.
  • License violations. Licensed code is redeployed on unauthorized domains or by unlicensed parties.
  • Weak legal footing. Copyright and contract disputes depend on showing that the disputed code originated with the claimant.

Why It Is Getting Harder

AI tools have lowered the cost of reading and rewriting code. An LLM can explain obfuscated JavaScript and help produce a functionally similar rewrite in minutes (see AI-Assisted Reverse Engineering). Collberg and Thomborson describe three classic attacks on watermarks:

  • Subtractive. Locating the mark and cutting it out.
  • Distortive. Applying semantics-preserving transformations, such as renaming, reordering, or re-minifying, until the mark can’t be recognized.
  • Additive. Inserting a second, competing watermark to muddy the ownership claim.

No watermark is removal-proof. Its strength depends on how well it is hidden and how well the surrounding code resists analysis and tampering.

Code Watermarking Best Practices

  • Layer it with obfuscation and anti-tampering. A watermark in readable code is easy to find and strip. The Purdue researchers concluded that watermarks need obfuscation and tamper-proofing to resist determined attacks.
  • Embed it in the build pipeline. Apply watermarks automatically in CI/CD, so every release is marked and no build ships unprotected.
  • Don’t rely on comments or formatting. Minifiers and bundlers remove them. Embed marks in structures that survive the production build.
  • Fingerprint distributed copies. Use a distinct mark per customer, partner, or environment when code leaves your control, so you can trace a leak to its source.
  • Keep the recognizer and keys secret. Anyone who knows how to find the mark can also find and remove it.
  • Record what you marked. Keep a log of each build, its watermark, and its date. Evidence is stronger when you can show when and where a mark was applied.
  • Test for side effects. Confirm that the watermarked build behaves identically and meets performance budgets, especially for dynamic marks.
  • Verify periodically. Check that marks survive framework upgrades and build-tool changes, and scan for copies of your code in the wild.
  • Involve legal early. Agree with counsel how watermark evidence will be collected and presented, and disclose watermarking in license terms where appropriate.

Solutions by Jscrambler

A watermark proves ownership, but it doesn’t stop anyone from reading, reusing, or tampering with the code it sits in. Jscrambler pairs ownership evidence with protection of first-party application logic wherever it executes, including in the browser.

  • LLM-Resilient Code Protection: Protects proprietary logic and commercial algorithms against AI-assisted inspection, reverse engineering, and manipulation. Code protection is key to ensure reliable code watermarking and traceability. 
  • Jscrambler Code Integrity: Includes Code Watermarking. Teams embed an ownership watermark in their protected code and can verify ownership of their JavaScript themselves (Jscrambler 101: Code Watermarking). The watermark ships inside code that Code Integrity also hardens with polymorphic obfuscation (every protected build differs from the last), anti-tampering, Self-Defending and Self-Healing, and Code Locks such as Domain Lock and Date Lock. Protection, watermark included, runs automatically on every build through CI/CD integrations.

FAQs

What is the difference between code watermarking and source code watermarking?

They describe the same practice. “Source code watermarking” stresses marking code before it is compiled or bundled. “Code watermarking” also covers marks embedded in production builds, bytecode, or runtime behavior.

Can a code watermark be removed?

A determined attacker can remove or distort a watermark if they can find it. Robust and dynamic watermarks raise the cost, and combining them with obfuscation and anti-tampering raises it further.

Does code watermarking affect performance?

Static marks usually have little or no impact. Dynamic marks add some code and runtime work, so teams should test watermarked builds against their performance budgets.

Can you watermark JavaScript?

Yes. Because JavaScript ships to the browser, watermarks must survive minification and bundling. They belong in the code’s structure or runtime behavior, not in comments.

A watermark is technical evidence that can support a copyright or contract claim. Its weight depends on the jurisdiction and the case, so involve legal counsel.

Related Resources