PHP end of life dates are set per branch. Current branches get two years of active support, then two years of security fixes only, ending on 31 December. PHP 8.1 reached end of life on 31 December 2025, and PHP 8.2 follows on 31 December 2026. PHP 8.3, 8.4 and 8.5 run to the end of 2027, 2028 and 2029.
Below: every recent branch with php.net's dates, why the PHP on your server may still be patched after php.net stops, what WordPress recommends, and what breaks between 7.4 and 8.x.
- PHP end of life isn't one date. Each branch gets two years of active support, then two years of security fixes only, ending on 31 December.
- On 30 October 2026, php.net supports PHP 8.2, 8.3, 8.4 and 8.5. PHP 8.2 reaches end of life on 31 December 2026; 8.1 ended on 31 December 2025.
- Red Hat lists PHP 7.4 on RHEL 8 and PHP 8.0 on RHEL 9 as full-life streams, so Red Hat's own packages can outlast php.net's dates.
- Moving from 7.4 to 8.x changes behavior: 0 == "foo" is now false, and many warnings became errors. Find those before the upgrade does.
PHP end of life dates for every branch
Four branches are supported on 30 October 2026.
| Branch | Released | Active support until | Security support until (end of life) |
|---|---|---|---|
| PHP 8.2 | 8 December 2022 | 31 December 2024 (ended) | 31 December 2026 |
| PHP 8.3 | 23 November 2023 | 31 December 2025 (ended) | 31 December 2027 |
| PHP 8.4 | 21 November 2024 | 31 December 2026 | 31 December 2028 |
| PHP 8.5 | 20 November 2025 | 31 December 2027 | 31 December 2029 |
Checked 30 October 2026 against PHP's supported versions page.
Every older branch has reached end of life:
| Branch | End of life | Last release |
|---|---|---|
| PHP 8.1 | 31 December 2025 | 8.1.34 |
| PHP 8.0 | 26 November 2023 | 8.0.30 |
| PHP 7.4 | 28 November 2022 | 7.4.33 |
| PHP 7.3 | 6 December 2021 | 7.3.33 |
| PHP 7.2 | 30 November 2020 | 7.2.34 |
| PHP 7.1 | 1 December 2019 | 7.1.33 |
| PHP 7.0 | 10 January 2019 | 7.0.33 |
Checked 30 October 2026 against PHP's end-of-life branches page.
Is PHP end of life?
- The language is maintained; individual branches reach end of life. PHP's supported versions page says "Each release branch of PHP is fully supported for two years from its initial stable release," and then "supported for two additional years for critical security issues only."
The four-year cycle is fairly new. The release cycle update RFC, dated March 2024 and accepted, added the second year of security fixes and moved end dates to 31 December. It applied from PHP 8.2 and gave 8.1 an extra year, which is why 8.1 ran to 31 December 2025 while older branches ended on scattered dates.
The middle phase matters. In security-only support, php.net releases "on an as-needed basis." PHP 8.2 and 8.3 are both there now, so a plain bug on either won't get a php.net fix.
When is PHP 8.2 end of life?
PHP 8.2 reaches end of life on 31 December 2026, after security-only support since 31 December 2024. The RFC gave it a year more than the original cycle would have. Next in line: PHP 8.3 end of life is 31 December 2027, and PHP 8.4 end of life is 31 December 2028, with 8.4's active support ending on 31 December 2026.
PHP end of life support: why your server may still be patched
php.net's date is when the PHP project stops. Your operating system vendor may support its own PHP package for longer. Red Hat's Application Streams life cycle page says "Each Application Stream component has a given life cycle, either the same as the RHEL release or shorter," and offers full-life streams: "a single stream that extends the duration of the underlying RHEL release."
| RHEL release | Full-life PHP stream | Shorter PHP streams, with Red Hat's retirement date |
|---|---|---|
| RHEL 8 | PHP 7.4 | 7.2 (May 2021), 7.3 (November 2021), 8.0 (November 2024), 8.2 (May 2029) |
| RHEL 9 | PHP 8.0 | 8.1 (May 2025), 8.2 (May 2029), 8.3 (May 2029) |
| RHEL 10 | PHP 8.3 | 8.4 (May 2029) |
Checked 30 October 2026 against the same Red Hat page.
So Red Hat's own PHP 7.4 package on RHEL 8 sits inside Red Hat's support life cycle, years after php.net's end of life. A PHP 7.4 you compiled yourself, or installed from another repository, gets nothing from Red Hat. A retired stream is worse off still: Red Hat says "Retired/Deprecated Application Streams packages do not receive updates or Errata."
Two cautions: a scanner reading the version string will still flag "7.4," so keep Red Hat's policy page ready for the auditor, and your framework sets its own minimum PHP version regardless. On other distributions, check that vendor's own page. For the wider picture, see the risks of running end-of-life software.
What is the best PHP version?
The newest branch your framework, extensions and hosting all support. On 30 October 2026, PHP 8.5 has active support to 31 December 2027 and PHP 8.4 to 31 December 2026.
For the PHP version for WordPress, WordPress's requirements page recommends "PHP version 8.3 or greater." It says WordPress also works with PHP 7.4 and later, but warns those versions "have reached their official End Of Life and may expose your site to security vulnerabilities."
What breaks moving from PHP 7.4 to 8.x?
Most of it lands in PHP 8.0. PHP's 8.0 migration guide lists the incompatible changes, and the 8.1 and 8.2 guides list the deprecations that fill logs next.
| Change | From | What it does to old code |
|---|---|---|
| String to number comparison | 8.0 | 0 == "foo" and 0 == "" were true and are now false, so loose checks can take a different branch |
| Warnings became errors | 8.0 | Wrong argument counts to built-in functions throw ArgumentCountError; arithmetic on an array (other than array + array) throws TypeError |
| Default error_reporting is E_ALL | 8.0 | Notices and deprecations that were hidden now reach the logs |
| @ no longer hides fatal errors | 8.0 | Error handlers that test error_reporting() == 0 need a mask check instead |
| Removed functions and old constructors | 8.0 | create_function(), each() and money_format() are gone; a method named after its class is no longer a constructor |
| PDO error mode | 8.0 | The default changed from "silent" to "exceptions", so a failed query throws |
| Null to built-in functions | 8.1 | Passing null to a non-nullable parameter is deprecated |
| Dynamic properties | 8.2 | Creating undeclared properties is deprecated unless the class uses #[\AllowDynamicProperties] |
The comparison change is the dangerous one, because nothing crashes: a check just takes a different path. Run the application on the new version in a test environment with every error logged, and pin current behavior with tests first, as in our guide to refactoring legacy code. See also our code audit checklist and how to reduce technical debt. PHP apps that run for years untouched are classic legacy system examples.
Before you choose a PHP version: how the 30-day assessment helps
A version number says how old the runtime is, not how much code depends on 7.x behavior. The 30-day assessment answers that. It's fixed in scope, at a price agreed before we start. Over 30 days we read the codebase and the architecture around it, map how the application fits together, cron jobs and libraries included, find the hidden architectural debt, and flag the security and compliance gaps, such as a PHP branch past end of life with nobody patching it.
The report says in plain language what is broken, what an upgrade to 8.4 or 8.5 would break, and what it would take to fix it. Your team can act on it, or we can do the upgrade as a separate project with its own scope and price. The report stands on its own either way. If the only question is which PHP a server runs and who patches it, we'll say so and point you to a narrower check.
Email Santosh a short list of your PHP applications, the version each runs, and where it's hosted.