Legal & Compliance
Published
This is general background for engineering and product teams, not legal advice, and trade-secret law varies by jurisdiction. Talk to counsel about your own facts. What follows is the shape of the question, because it comes up whenever a company realises its most valuable logic is being handed to every visitor several hundred times a second.
The standard, and why client-side code sits awkwardly against it
Trade-secret regimes differ in detail but converge on two requirements. The information has to derive commercial value from not being generally known, and the holder has to take measures that are reasonable in the circumstances to keep it secret.
The second requirement is where JavaScript struggles. A browser bundle is transmitted, in full, to anyone who requests it — including people who have agreed to nothing and owe you no duty. That is not an incidental leak; it is the delivery mechanism working as designed. Arguing that something published to the entire internet was kept secret is a steep hill, and it is a hill you climb before anyone even examines what the code does.
This is why experienced counsel tends to move the question rather than answer it. The defensible secret is rarely the bundle. It is the server-side implementation, the parameters and weights that never leave your infrastructure, the operational data, and the internal source tree with its comments, history and design documents — none of which you publish.
What obfuscation actually contributes
Two things, both real and both narrower than the marketing in this industry suggests.
It is a measure that applies to material you have already distributed. Most of the reasonable-measures checklist — access control, need-to-know, confidentiality agreements, physical security — presumes you can restrict who receives the information. For a public bundle you cannot. Obfuscation is one of the few controls that still does work after distribution, alongside contract terms and marking. If the assessment is whether you treated the material as confidential or as public, having applied a protection step is a different posture from shipping readable source with the comments intact.
It generates a dated, verifiable record. This is underrated. A protection run produces a report and a manifest with per-file hashes; a watermark ties a specific artifact to a specific recipient; a signed release attestation establishes that a given build is the one you published. Those artifacts are contemporaneous evidence of what you did and when. Disputes are frequently lost not because the measures were inadequate but because the holder could not demonstrate, years later, what was in place at the time.
What obfuscation does not do is convert public code into a secret. Behaviour remains observable even when text is unreadable — anyone can watch what requests your code makes and what outputs follow which inputs. If the valuable idea is visible in the behaviour, transforming the text does not conceal it.
The practical division
The useful exercise is sorting your own logic into three buckets, which most teams have never explicitly done.
- Must never be client-side. Pricing and rating formulas, scoring and ranking logic, matching or allocation algorithms, fraud and risk heuristics, model parameters, and any credential at all. Shipping these discloses them no matter what you do to the text. Move them behind an API and the problem becomes ordinary infrastructure security.
- Client-side by necessity, worth protecting. Rendering pipelines, real-time interaction logic, offline-capable features, licence and entitlement checks, and the accumulated engineering that makes your interface hard to imitate. This has to run in the browser to work. Protect it, watermark it, and set expectations honestly about what that achieves.
- Not worth the argument. Framework code, utility helpers, and anything a competent engineer would write the same way. Protecting it is free because it rides along in the same build; claiming it as a secret is not credible and dilutes the claims that are.
Teams that do this sorting usually discover at least one item in the first bucket that is currently shipping in the second. That discovery is worth more than any protection setting.
Measures that surround the technical one
Reasonable measures are assessed as a programme, so the technical control is judged in company with everything else. The items that carry weight are unglamorous and mostly organisational: confidentiality terms in employment and contractor agreements, access scoped to need rather than convenience, offboarding that actually revokes, marking confidential material as confidential, NDAs before disclosures to partners and prospects, and defined handling terms wherever source is shared under diligence or escrow arrangements.
Note how much of that concerns people rather than artifacts. That is the same conclusion reached from a different direction in obfuscation and the insider threat: the shipped bundle is one exposure surface among several, and it is not the one most leaks travel through.
Keeping notices intact
One practical detail that cuts across both directions. Aggressive comment stripping removes copyright and licence headers, and permissive licences such as MIT, BSD and Apache-2.0 generally require you to preserve attribution notices for the third-party code in your bundle. Keeping a licence banner is a compliance obligation to others and a small assertion of your own rights at the same time. Preserving the leading banner comment while protecting everything else is a supported configuration, and is JavaScript obfuscation legal covers the licence side in more depth, including where copyleft terms make obfuscated distribution the wrong answer entirely.
The short version
Do not build a trade-secret strategy on your JavaScript bundle. Move genuinely secret logic server-side, where secrecy is achievable and defensible. For what must ship, protect it, watermark it per recipient, retain the reports and attestations that prove what you did and when, and keep the organisational measures in good order — those are what an assessment of reasonableness actually looks at. Obfuscation is a legitimate contributor to that programme and a poor substitute for it, and any vendor selling it as legal armour is describing a product that does not exist.
Frequently asked questions
Can JavaScript that ships to a browser still be a trade secret?
It is difficult, and the difficulty is structural rather than technical. Trade-secret protection generally requires that information derive value from not being generally known and that the holder take reasonable measures to keep it secret. Code delivered to every visitor is, by construction, disclosed to the public. Practitioners tend to treat the shipped bundle as weak ground and locate the defensible secret elsewhere — in server-side logic, in models and parameters that never leave your infrastructure, and in the internal source with its comments and history. This is general background, not legal advice; ask counsel about your specific facts.
Does obfuscating my code count as a reasonable measure to keep it secret?
It is plausibly one measure among several, and it is unusual in that it is one of the few that can apply to code you have already published. Reasonable measures are assessed as a programme rather than a single step: access controls, confidentiality agreements, marking, offboarding and technical controls together. Obfuscation is evidence that you did not simply publish the material in readable form and treat it as public. What it will not do is carry the argument by itself, and no vendor should tell you otherwise.
What should I actually keep out of the client bundle?
Anything whose value depends on nobody else knowing it. Pricing and rating formulas, scoring or ranking logic, matching and allocation algorithms, fraud heuristics, model parameters and thresholds. If that logic runs in the browser it is disclosed to every user regardless of how it is transformed, because behaviour can be observed even when code cannot be read. Move it behind an API and the secrecy question becomes a straightforward infrastructure-security question, which is a much better position to argue from.
Does obfuscation affect my copyright in the code?
Copyright and trade secrecy are separate regimes and obfuscation does not change ownership. Copyright attaches to the expression you authored and survives transformation of the distributed form. It is worth keeping copyright notices intact in shipped output rather than stripping every comment — preserving a licence or attribution header is also what permissive third-party licences require of you, which is a compliance point independent of your own rights.
If someone deobfuscates my code, have they done something unlawful?
Not automatically, and the answer depends heavily on jurisdiction and on how they obtained the code. Reverse engineering something you lawfully possess is permitted in many contexts and expressly protected in some. Where liability tends to arise is around the surrounding conduct: breaching contract terms they accepted, circumventing an access control, misappropriating something obtained in confidence, or infringing copyright by redistributing the result. Treat obfuscation as raising cost, not as creating a legal trigger.
What evidence should I retain in case I ever need to make this argument?
Retain the things that show a deliberate, ongoing programme rather than an after-the-fact claim. Dated build reports and manifests establishing what was protected and when, watermark issuance records tying a specific artifact to a specific recipient, signed release attestations, your access-control and offboarding records, and the confidentiality terms in your employment and customer contracts. The recurring theme in disputes is that the holder could not show what measures were in place at the relevant time — and that is a record-keeping failure rather than a technical one.
Related reading