Which PHP Versions Does ionCube Support?

If you run encoded PHP applications, sooner or later you will ask which PHP versions the encoding system supports. The question usually comes up right before a planned PHP upgrade, when you need to know whether your encoded software will still run. The honest answer is nuanced: support is not a single number, it is a moving relationship between three things, your PHP version, your loader, and the tool used to encode your files.

This guide explains how PHP version support actually works so you can plan upgrades without breaking your applications. It is written for owners and administrators of the software in question. If you are advising someone else, make sure you are authorized to make decisions about their environment.

Support Is a Three-Way Relationship

Think of three moving parts:

1. The PHP version your server runs.
2. The loader installed as a PHP extension.
3. The encoding version used when your files were protected.

All three must line up. A given loader supports a specific set of PHP versions. A file encoded with a particular tool version requires a loader at least that new. And PHP itself changes between major versions in ways that require updated loader builds. "Which PHP versions are supported" really means "which PHP versions does your specific loader support, for files encoded with your specific tool version."

Loaders Track PHP Releases

As each new PHP version is released, loader builds are updated to support it. This means the current loader generally covers the PHP versions that are current and recently past, while very new PHP releases may need a freshly updated loader.

The practical takeaway: if you are moving to a recent PHP version, make sure you also have a recent loader. An older loader will not know how to attach to a PHP version released after it was built. Our ionCube Loader explained guide describes this dependency.

Older PHP Versions Eventually Age Out

Just as new PHP versions need new loaders, very old PHP versions eventually fall outside what current loaders support. If you are running an ancient PHP release, you may find that only older loader builds work with it, and that those builds cannot run files encoded with the newest tools.

This matters for security as much as compatibility, since old PHP versions stop receiving security fixes. Staying on a supported, reasonably current PHP version keeps you inside the well-supported range for both PHP and the loader.

How to Check Your Own Compatibility

Rather than relying on general statements, check your specific situation:

• Find your PHP version with php -v or a phpinfo() page.
• Find your loader version in the loader section of phpinfo(). See our guide on checking the loader version if you are unsure where to look.
• Note whether your PHP build is thread-safe, since the loader must match that too.

With those three facts you can determine whether your current setup is coherent, and what you would need to change before a PHP upgrade. Our encoded PHP and PHP upgrades article walks through the upgrade planning in more detail.

Planning a PHP Upgrade Safely

When you intend to move to a newer PHP version, plan the loader and application together:

First, confirm that a loader build exists for your target PHP version and install it as part of the upgrade, not after. Second, verify that the encoded application itself was built to run on your target PHP version; the vendor may need to supply an updated build if it was only ever encoded for an older PHP series. Third, test in a staging environment before touching production, because a version mismatch is much easier to fix when no live traffic depends on it.

The most common upgrade failure is forgetting the loader, upgrading PHP, keeping the old loader, and finding that encoded files no longer run. Treating the loader as part of the upgrade avoids that.

When the Application, Not the Loader, Is the Limit

Sometimes the loader supports your target PHP version but the application still fails. That points to the application itself being encoded for an older PHP series and not written to run on the newer one. This is not a loader problem and not something to work around; it is a request to the vendor for a build targeting your PHP version. Language changes between major PHP releases can require the software's actual code to be updated, which only the vendor can do.

Getting Off the Version Treadmill

If managing this three-way compatibility every upgrade cycle is a burden, and you are the authorized owner of the software, there is an alternative. Recovering plain PHP source from your encoded files removes the loader and encoding-version parts of the equation entirely. Plain PHP runs on any compatible PHP version, and you upgrade it like any other codebase, testing and adjusting the code directly.

This is an owner-authorized process. Confirm your rights, then see how our ionCube decoder and PHP decompiler support it. Just remember that recovered source, like any codebase, still needs normal review when you move it across major PHP versions.

FAQ

Is there one PHP version that ionCube supports? No. Support spans a range that shifts over time as new PHP versions are released and loaders are updated. Your effective support depends on your loader version and how your files were encoded.

Will my encoded app run on the newest PHP version? Only if a loader build exists for that PHP version and the application itself was encoded to run on it. Check both before upgrading.

How do I check what my current setup supports? Note your PHP version, your loader version, and your PHP build type from php -v and phpinfo(). Those three facts define your compatibility.

What if the loader supports my PHP version but the app still breaks? The application was likely encoded for an older PHP series. That requires an updated build from the vendor, since language changes may affect the code itself.

Can I avoid this compatibility juggling entirely? As an authorized owner, recovering plain source removes the loader and encoding-version dependencies. See the FAQ or start a free trial.