Which PHP Version Should You Run for WordPress in 2026?

WordPress.org's own requirements page still lists "PHP 8.3 or greater" as the recommendation. That's not wrong exactly, but it's slightly out of step with where PHP's own release cycle is in 2026: PHP 8.3 exited active support at the end of 2025 and now only receives security fixes, and PHP 8.5 has been out since November 2025. If you're choosing a PHP version for a new WordPress site, or deciding whether to upgrade an existing one, "whatever the requirements page says" isn't quite specific enough anymore.

This covers where each PHP version actually stands right now, what WordPress core supports, and what a sensible choice looks like depending on whether you're running a stable production site or setting something up fresh.

TL;DR

• PHP 8.4 and 8.5 are the only versions currently in active support from the PHP project; PHP 8.2 and 8.3 have moved into security-fixes-only mode, and anything older than 8.2 is fully end of life.
• WordPress core (as of 7.0) supports PHP versions from 7.4 through 8.5, and dropped the old "beta" labeling for new PHP releases in 2026, meaning 8.4 and 8.5 are now treated as fully supported, not experimental.
• For most production WordPress sites, PHP 8.4 is the pragmatic default in mid-to-late 2026: it's stable, actively supported until the end of 2026 with security fixes through 2028, and has had over a year of real-world plugin and theme compatibility testing.
• PHP 8.5 is a reasonable choice for new sites or anything you're actively developing, since it has the longest support runway, but budget time to test plugins and custom code that haven't been updated recently.
• Running WordPress on PHP 8.1 or earlier means running on software that no longer receives security patches at all, regardless of what WordPress itself supports.

PHP Version Support Status in 2026

PHP versions move through a fixed lifecycle: two years of active support (bug fixes and security patches), followed by two more years of security-fixes-only support, then end of life. Here's where the versions relevant to WordPress sites currently stand, per the PHP project's own supported-versions page:

Anything before PHP 8.2 has left the support window entirely and receives no fixes of any kind, including for actively exploited security issues.

Important: "Security fixes only" doesn't mean unsafe today. It means new features and non-critical bug fixes have stopped, and the version has a defined expiration date after which it becomes genuinely risky to keep running.

What WordPress Actually Recommends and Supports

WordPress.org's requirements page recommends PHP 8.3 or greater, with a documented minimum of PHP 7.4 (older versions technically still run WordPress but are unsupported and insecure). Under the hood, WordPress core aims to support new PHP versions in step with its own major releases each November, and as of WordPress 7.0, core supports the full range from PHP 7.4 through PHP 8.5.

One change worth knowing about: in a spring 2026 clarification post, the WordPress core team retired the old practice of labeling brand-new PHP versions as "beta" support until they reached 10% adoption across WordPress sites. That labeling was found to discourage plugin and theme authors from testing against newer PHP versions promptly, which slowed the whole ecosystem's readiness. PHP 8.4 and 8.5 are now treated as fully supported by WordPress core, not experimental.

Put plainly: WordPress's public recommendation (8.3+) is a floor, not a target. It was accurate when written, but PHP's own lifecycle has moved past it. Treat "8.3 or greater" as "at minimum 8.3, but you're choosing between 8.4 and 8.5 in practice."

Why the PHP Version You Run Actually Matters

Security. This is the least optional reason. Running a PHP version that no longer receives security patches means any vulnerability discovered after its end-of-life date simply never gets fixed on your server, regardless of how well-configured everything else is. WordPress's own core security depends partly on the PHP layer underneath it.

Performance. Each major PHP version has generally improved raw execution performance over the last several release cycles, largely through internal engine optimizations rather than anything a site owner has to configure. Sites doing heavy PHP work, complex WooCommerce catalogs, custom plugins, page builders with a lot of server-side rendering, tend to benefit the most from staying current.

Compatibility. This cuts both ways. Newer PHP versions deprecate old language features and sometimes remove them outright, which can break poorly maintained plugins or old custom code. But staying too far behind creates the opposite problem: modern plugins and themes increasingly assume a reasonably current PHP baseline, and some newer plugin releases quietly drop support for very old PHP versions.

PHP 8.4 and 8.5: What's Actually Different

Both are currently in active support, and WordPress core supports both. The practical difference for most WordPress site owners is less about specific language features and more about maturity and support runway:

• PHP 8.4 has been out since November 2024, giving plugin and theme developers over a year to find and fix compatibility issues against it by mid-2026. It remains in active support through the end of 2026 and receives security fixes until the end of 2028.
• PHP 8.5 is the newest release, out since November 2025. It has the longest support runway of any current version, active support through the end of 2027 and security fixes through 2029, but has had less real-world exposure across the plugin ecosystem simply because it's newer.

Neither is the wrong choice. The decision mostly comes down to risk tolerance and how actively maintained your plugin stack is.

The Practical Recommendation for 2026

For an existing production site with a typical mix of plugins: PHP 8.4 is the sensible default right now. It's actively supported, has a long runway before you'll need to think about this again, and has enough real-world adoption that most actively maintained plugins and themes have already been tested against it.

For a brand-new site, or one you're actively developing and controlling the full plugin list for: PHP 8.5 is a reasonable choice, since you're not depending on years of legacy compatibility and you get the longest support window available.

For a site still running PHP 8.2 or 8.3: neither is an emergency today, but 8.2's security support ends at the close of 2026 and 8.3's ends at the close of 2027. Plan the move to 8.4 or later before those dates rather than after, since scrambling to test a PHP upgrade under deadline pressure is a worse experience than doing it on your own schedule.

For a site still running PHP 8.1 or earlier: this is the case that actually deserves urgency. You're running on software with no security fixes at all, on a platform (WordPress) that handles public-facing forms, logins, and often payment-adjacent data.

How to Check and Change Your Site's PHP Version

Most WordPress installs surface the current PHP version in Tools → Site Health → Info, under the Server section. If you have SSH access, wp cli info (via WP-CLI) reports the PHP version WordPress is actually running on, which is more reliable than checking a hosting dashboard that might reflect a default rather than the version assigned to your specific site.

Changing the PHP version itself is typically a hosting-level setting rather than something WordPress controls directly, so the exact steps depend on your host. Regardless of host, the safer sequence is the same:

1. Check your current version via Site Health or WP-CLI, and note it down.
2. Test the new PHP version on a staging copy first, not production. A staging environment lets you click through the admin, front end, checkout (if you run WooCommerce), and any custom functionality before committing.
3. Back up before changing anything on the live site, so a rollback is available if something you didn't catch on staging surfaces in production.
4. Watch for deprecation notices and fatal errors in the days after the change, not just in the first few minutes. Some issues only surface on code paths that don't run on every page load.

Important: Take a fresh backup immediately before making the change on production, even if staging looked clean. MagicWP's on-demand backups and one-click staging cover both steps from the same dashboard, and SSH with WP-CLI access is available on every MagicWP site for checking the running version directly.

Common Compatibility Pitfalls When Upgrading PHP

Old, unmaintained plugins. A plugin that hasn't been updated in two or three years is the most common source of PHP upgrade breakage, since it was likely written against an older PHP baseline and may use deprecated or removed function calls.

Custom theme or plugin code. If you or a past developer wrote custom functionality, search it for deprecated function usage before upgrading, particularly anything involving dynamic properties, string-to-number comparisons, or older array-handling functions, all common sources of PHP version deprecation warnings.

Third-party integrations that shell out to PHP directly, such as custom cron scripts or command-line tools outside of WordPress itself, which won't be caught by testing the WordPress admin and front end alone.

Assuming a clean staging test means a clean production result. Staging should closely mirror production, but traffic patterns, cron timing, and edge-case content (unusual characters, very large data sets) can behave differently under real load. A quick check in the days after a production PHP change, not just before it, catches what staging sometimes doesn't.

Frequently Asked Questions

What PHP version does WordPress recommend in 2026? WordPress.org's requirements page recommends PHP 8.3 or greater. In practice, since PHP 8.3 exited active support at the end of 2025, PHP 8.4 or PHP 8.5 is the more forward-looking choice for a site being set up or upgraded in 2026.

What's the minimum PHP version WordPress will actually run on? WordPress documents a minimum of PHP 7.4, though that version is long past end of life and running it is a security risk regardless of whether WordPress technically still functions on it.

Is PHP 8.3 still safe to use for WordPress? It's still receiving security fixes through the end of 2027, so it's not an immediate risk, but it's no longer in active support. It's a reasonable version to be migrating away from over the next year rather than staying on indefinitely.

Should I upgrade to PHP 8.5 right away? If you're setting up a new site or actively maintain your full plugin list, yes, it's a solid choice with the longest support runway. For an existing site with plugins you don't control closely, PHP 8.4 currently has more real-world compatibility testing behind it.

How do I check what PHP version my WordPress site is running? Go to Tools → Site Health → Info in wp-admin and check the Server section, or run wp cli info over SSH if you have command-line access to the server.

Will upgrading my PHP version break my plugins or theme? It can, especially with older or poorly maintained plugins that use deprecated PHP functions. Testing on a staging copy before applying the change to a live site is the reliable way to find out before it affects visitors.

What happens if I run WordPress on an end-of-life PHP version? You stop receiving security patches for the PHP layer entirely, even though WordPress itself may continue to function. Any vulnerability discovered in that PHP version after its end-of-life date will never be fixed, which is a materially different risk than running a version that's merely out of active support.

Does WordPress core still label new PHP versions as "beta" support? No. As of a spring 2026 clarification from the WordPress core team, that labeling was retired. PHP 8.4 and 8.5 are treated as fully supported by WordPress core rather than experimental.

Conclusion

The right PHP version for WordPress in 2026 isn't really a single number, it's a range with a clear best answer depending on your situation: PHP 8.4 for most existing production sites, PHP 8.5 for new builds and actively maintained stacks, and a real plan to move off anything at 8.2 or 8.3 before their respective security windows close. What matters more than the exact version is treating the change like any other core infrastructure update: check what you're running, test it on staging, back up before touching production, and watch for issues after the change, not just before it.