Obfuscation vs encryption
Encryption uses a key to protect confidentiality. Obfuscation makes code harder to read but provides no confidentiality: a user can download the code, run it in DevTools and analyse its behaviour.
When can it help?
- Discouraging casual copying of small business-logic fragments.
- Making a client-delivered library less immediately readable.
- Adding friction to simple scraping while recognising that it is not full protection.
- Removing debug logs before shipping when the build pipeline does it safely.
What not to do
- Do not put secrets in JavaScript because the code is obfuscated.
- Do not use obfuscation to hide malware or trackers from users.
- Do not treat it as a replacement for server-side authorization.
- Measure bundle size and execution time because heavier code can hurt performance.
Example and regression checks
Renaming calculateTotal to a obscures its name, but inputs and outputs remain observable at runtime. A public source map can reveal original code. After transformation, compare critical paths, CSP errors, size and execution time; retain private maps for debugging.
function calculateTotal(price, count) { return price * count; }
// ↓
function a(b, c) { return b * c; }It is a transformation that makes JavaScript names, strings or control flow harder to read quickly. The code remains available in the browser and can still be analysed.
Passwords, private API keys and authorization rules belong on the backend. Public identifiers or publishable keys may be used in browsers according to the provider’s security model and restrictions. Obfuscation does not change that model.
No. Obfuscation adds reading friction but provides no confidentiality and does not replace security controls.
Sources & further reading
- MDN — JavaScript docs
- OWASP — Client-Side Security docs