How to protect PHP source code: a complete guide

PHP is an interpreted language: the files you deploy are the source code. Anyone who can read the server’s files — a customer, their hosting provider, a contractor, or whoever downloads a copy of your product — can read, change and redistribute your work.

For a lot of projects that’s fine. But if you sell a plugin, deliver a project to a client’s server, or ship self-hosted software, you may want some control over who can read and run your code. This guide walks through the options, from the simplest to the strongest, and is honest about what each one actually protects.

First, decide what you’re protecting against

Different goals need different tools:

• Casual copying and editing. A customer opens a file, changes a price check, and passes the result on. Most protection methods stop this.
• Unlicensed use. Someone runs your software on more sites than they paid for, or after their subscription ended. This needs licensing, not just hiding code.
• A determined reverse engineer. Someone with full control of a server and plenty of time. No method makes code impossible to recover in that situation; good protection makes it slow and expensive enough not to be worth it.

Keep these three in mind as you read: a method that’s excellent against the first may do nothing about the second.

Option 1: Don’t ship the code at all

The strongest protection is to keep the valuable part on your own servers and expose it as an API or a hosted service. Customers get a thin client — or just a URL — and the logic never leaves your infrastructure.

Good for: products that can run as a service. Not possible when: the software must run on the customer’s own server — WordPress plugins, self-hosted apps, client projects with data that can’t leave their environment.

If you can go this route for the part that matters most, do. For everything else, read on.

Option 2: Obfuscation

Obfuscators rewrite your code so it’s hard for humans to follow: variables and functions get meaningless names, comments and formatting disappear, and strings may be scrambled. The result is still plain PHP that runs anywhere.

Pros: free or cheap tools exist, nothing to install on the server, works on any host. Cons: it’s reversible to a large degree. A code formatter restores the structure, and the logic is all there to read — just with worse names. Any check you add (like a license check) can still be found and removed by editing the file.

Obfuscation raises the bar slightly. It does not stop someone who wants to change your code.

Option 3: Encoding (encryption with a loader)

A PHP encoder encrypts your files and replaces them with protected versions that only run when a matching loader — a PHP extension — is installed on the server. The loader decrypts and runs the code in memory; the files on disk stay unreadable.

This is how ionCube, SourceGuardian and Oxrion work. Compared with obfuscation:

• The source on disk isn’t readable at all, not just hard to read.
• Protected files are typically signed, so a modified file refuses to run — which makes it far harder to strip out checks.
• Encoders can enforce rules when the file runs: an expiry date, a required license, or a key that must exist on the server.

The trade-off: the loader must be installed on every server that runs the code. On a VPS or dedicated server that’s a one-time setup. On shared hosting, the hosting provider has to offer it — check this before choosing an encoder, because it decides where your customers can run your software.

Option 4: Licensing

Hiding code and controlling where it runs are different problems. Licensing answers questions like which site is allowed to run this and until when.

A common pattern is a license bound to a domain, signed with a private key that only you hold. The software checks the signature with the matching public key, so a customer can’t forge or edit a license. You can do this yourself with PHP’s built-in sodium functions — but if the code doing the check is readable, anyone can delete the check. Licensing is only as strong as the protection of the code that enforces it, which is why encoders usually include licensing.

Option 5: The legal layer

Whatever technical method you choose, your license agreement (EULA or terms) is what gives you legal recourse when someone copies or resells your work. It should say what customers may and may not do — for example, run the software on one site, no redistribution, no reverse engineering where the law allows such a restriction.

If you build on open-source code, check its license too. Code licensed under the GPL, for example, gives everyone who receives it the right to its source, and encoding it conflicts with that.

Which option is right for you?

Your situation	Best fit
The valuable part can run as a service	Keep it server-side (API / SaaS)
You just want to discourage casual reading	Obfuscation
Code runs on customer servers and must not be read or changed	Encoding
You need to control which sites run it, and for how long	Encoding + licensing
You distribute under the GPL	None of the above for the code itself — sell updates and support instead

What protection can’t do

Be wary of anyone promising unbreakable PHP protection. Code that runs on a machine has to be decrypted on that machine, so someone with full control of the server and enough time can eventually get at it. What good protection does is make that slow, expensive and clearly unauthorized — enough to stop casual copying, unlicensed installs and easy reselling, which is what most developers actually need.

Protecting PHP with Oxrion

Oxrion is a PHP encoder with licensing built in. You choose files in the free Oxrion Desktop app, they’re protected and returned, and they run on your customers’ servers with the free Oxrion loader. One protected file works on every supported PHP version. You can bind files to a license for each customer’s domain, set an expiry, lock them to a server, and — if you choose — restore your own source later with your own key.

See how it works, or start on the free plan.