WordPress Plugins

You can’t obfuscate a wordpress.org plugin — and you mostly don’t need to.

Two honest facts change this question completely. First, the WordPress.org plugin directory guidelines require human-readable code and forbid obfuscation — even minified assets must ship with their source. Second, and more usefully: a plugin’s real value is usually its PHP, which runs on the server and is never sent to a browser. Your moat is already protected by where it runs. The JavaScript is the part that does ship — so the real questions are what’s allowed, and what’s actually worth protecting.

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

“Code must be (mostly) human readable.”

WordPress.org Detailed Plugin Guidelines. Obfuscation is not permitted; minification is fine only if you also provide the human-readable source.

PHP: server-sideNever shipped — protected by architecture.
Directory JS: readableObfuscation banned; minify + provide source.
Secrets: server-sideNever in plugin JavaScript.
The Reframe

Your plugin’s moat is already off the client

The instinct to “protect my plugin’s code” usually pictures hiding the whole thing. But a WordPress plugin is mostly PHP, and PHP executes on the server — the browser only ever sees its output, never its source. Your database queries, business rules, integrations, and licensing logic are protected the strongest way anything can be: by never being sent at all. That is the opposite of a client-side secret, and it means the anxiety about “someone stealing my plugin” is largely answered before obfuscation enters the picture.

PHP — already protected

Server-side and never shipped. This is where a plugin’s real value lives, and it is safe by architecture. Obfuscating PHP would only hurt maintainability — and the directory forbids it anyway.

Directory JS — must be readable

The guidelines require human-readable code. You may minify for performance, but you must provide the unminified source or a link to it. Shipping only obfuscated JS gets a plugin rejected.

Secrets — never in the bundle

Plugin JavaScript is served to every visitor. A license key or API secret in it is public; obfuscation only delays discovery. Keep secrets in PHP and expose results, not credentials.

Directory Plugins

Play by the rules — and lean on architecture

  • Don’t obfuscate. It’s prohibited, and for a directory plugin it’s also mostly unnecessary given your PHP is server-side.
  • Minify, but publish source. Minified JS/CSS is allowed only alongside the human-readable source or a clear link to it, plus your build tools.
  • Keep validation server-side. License checks and entitlement logic belong in PHP, not in JavaScript that anyone can read and edit.
  • No secrets in shipped assets. Read them in PHP; never inline a key into an enqueued script.
Premium / Off-Directory Plugins

Where JS obfuscation genuinely applies

  • Plugins distributed outside wordpress.org — from your own store or a marketplace whose rules permit it — where you control distribution. Confirm that channel’s readability rules first; some have their own.
  • Client-side JavaScript with real logic — interactive builders, in-browser processing, proprietary UI behavior. That code has to ship, so obfuscation raises the cost of copying it.
  • Still keep licensing authoritative on your server. Obfuscation protects the JS; it does not replace server-side entitlement. A client-only license check is a client-only speed bump.
Frequently Asked

WordPress plugin protection, answered honestly

Can I obfuscate a directory plugin?

No — the guidelines require human-readable code and forbid obfuscation. Minify only if you also provide the source.

So how is my plugin protected?

By architecture. The PHP that holds your real value runs on the server and is never shipped — the strongest protection there is.

Is minifying enough for the rules?

Only with the unminified source (or a link) and build tools provided. Minify to ship; keep the source public.

Where does obfuscation apply?

Premium plugins distributed off-directory, and client-side JS with genuine logic. Check the channel’s rules first.

Can I hide a license key in the JS?

No — it’s served to every visitor and is public. Keep it in PHP; validate on the server.

Should I obfuscate my PHP?

No — it’s already server-side, obfuscation hurts maintainability, and the directory prohibits it. Protect the JS you ship, not the code that never leaves your server.

Start Right

Protect what ships; trust the server for what doesn’t

For a wordpress.org plugin, don’t reach for obfuscation — it’s prohibited, and your PHP moat is already server-side. Minify and publish source per the rules, keep secrets and licensing in PHP, and use obfuscation only for off-directory premium plugins and the client JavaScript that genuinely carries logic worth protecting.

Try Online Obfuscator › Match protection to your threat model