Browser Extensions

If you’re publishing to the Chrome Web Store, don’t obfuscate — you’ll be rejected.

This is the honest answer, and it’s the opposite of what most “protect your extension” advice says. The Chrome Web Store’s Developer Program Policies prohibit obfuscated code — the rule applies to Manifest V3 and to any code the extension fetches — and obfuscated extensions get removed. Minification is allowed. So for a store extension, the question isn’t “how do I obfuscate it,” it’s “what actually protects code I’m required to ship readable.”

Try Online Obfuscator Secrets belong server-side
The Policy, Verified

“Developers must not obfuscate code.”

Chrome Web Store Developer Program Policies, Code Readability Requirements. Minification (whitespace, comments, shorter names) is permitted; concealing functionality is not.

Minify: yesAllowed — it doesn’t hide behavior.
Obfuscate: noRejected for store distribution.
Remote code: noMV3 forbids fetching+running remote scripts.
The Constraint

An extension is code you must ship readable — and readable to everyone

Two facts define this problem. First, the store requires readable code: Google’s reviewers and scanners have to be able to see what an extension does, because extensions run with broad access to the pages a user visits. Second, even without that policy, an extension offers no hiding place — a published extension is a downloadable archive anyone can unpack and read, with no server in front of it. So “hide the code” fails on both counts: the store won’t allow it, and it wouldn’t work anyway. Protection has to start from the assumption that the code is readable.

Minification — allowed, modest

Removing whitespace, comments, and shortening local names is explicitly permitted and worth doing. It raises the annoyance of casual reading without concealing behavior — which is exactly why the policy tolerates it.

Obfuscation — disallowed for the store

String encryption, control-flow flattening, and VM bytecode all conceal functionality, which is precisely what the policy forbids. Ship those to the Chrome Web Store and you risk rejection or removal.

Remote loading — also closed

Manifest V3 bans remotely hosted code, so you can’t sidestep the readability rule by fetching and running a script from your server. The reviewable code is the code that runs.

What Actually Protects It

Move the value off the client — the same rule as any web app

If the code can’t be hidden, then nothing worth hiding should be in it. That reframes the whole problem into one you already know how to solve:

  • Keep secrets server-side. API keys and credentials in an extension are public the moment it ships — unpack the archive and read them. Put them behind your API and have the extension call it. (See why you can’t hide a key in JavaScript.)
  • Keep proprietary logic server-side too. If an algorithm is your moat, run it on your server and expose a result, not the method. The extension becomes a thin, reviewable client.
  • Minify for the store. Permitted, and it trims the casual-reading surface without tripping the policy.
  • Assume the manifest and permissions are read. Request the narrowest permissions you can justify — reviewers and users both look.
Where Obfuscation Belongs

Code you distribute yourself, not through a store

Obfuscation is still the right tool — just not for store-published extension code. It applies cleanly to:

  • Extensions distributed outside a public store — enterprise or internally-hosted extensions, unpacked builds, or your own channel — where the store readability policy doesn’t apply.
  • The web application your extension talks to. Its client-side logic isn’t governed by extension-store rules and is exactly what an obfuscator protects.
  • Any non-Chrome target with different rules — always confirm the specific store or channel’s policy before shipping; several have their own review requirements.
Frequently Asked

Extension protection questions, answered honestly

Can I obfuscate a Chrome extension?

Not for the store — the policy prohibits obfuscated code and it gets rejected. Minification is allowed. Obfuscation is for code you distribute yourself.

Why does the store ban it?

So the code can be reviewed. Extensions are powerful; Google requires readable code to see what they do. Minification doesn’t conceal behavior, so it’s fine.

Would obfuscating even help?

Weakly. The package is a downloadable archive with no server in front of it — anyone can unpack and read it. Assume the code is public.

Can I load my real code remotely?

No — Manifest V3 forbids remotely hosted code. The code that runs is the code that’s reviewed. Design for that.

So what do I actually do?

Keep secrets and proprietary logic on your server; make the extension a thin client; minify for the store. That’s the protection that survives an unpacked archive.

Is there any place for obfuscation?

Yes — self-distributed/enterprise extensions outside a store, and the web app your extension talks to. Just confirm each channel’s policy first.

Start Right

Design the extension as if the code is public — because it is

For a store extension, don’t reach for obfuscation; you’d be rejected and it wouldn’t help. Move secrets and proprietary logic behind your API, minify what ships, and request minimal permissions. Then, for the code you do control end to end — self-distributed extensions and the web app behind them — use the obfuscator where it genuinely raises the cost of copying.

Try Online Obfuscator › Match protection to your threat model