PHP version stats: January, 2025
Happy new year! Twice a year, I write an update on PHP version usage across the community. You can read the previous edition here, but I'll also include historic data in this post.
As always, I'm working with the data available: these charts are not a 100% accurate representation of the PHP community as a whole, but they are an accurate representation of one of the most prominent parts of PHP: the packagist ecosystem.
Let's see what has changed over the past six months, and also check out how PHP 8.4 is doing, a month after its release.
# Usage Statistics
Let's start by looking at the percentage of PHP versions being used today. I've omitted all versions that don't have more than 1% usage:
Version | 2023-07 | 2024-01 | 2024-07 | 2025-01 |
7.2 | 4.3% | 2.5% | 2.0% | 1.6% |
7.3 | 4.2% | 3.2% | 1.9% | 1.5% |
7.4 | 19.9% | 13.6% | 10.2% | 7.6% |
8.0 | 12.3% | 7.2% | 5.4% | 3.4% |
8.1 | 39.3% | 35.2% | 26.1% | 18.1% |
8.2 | 17.2% | 29.4% | 32.3% | 28.6% |
8.3 | 0.2% | 6.4% | 19.9% | 32.7% |
8.4 | 0.0% | 0.0% | 0.0% | 5.1% |
Visualizing this data looks like this:
Ever since PHP 8.1, I've begun making these posts in January and July. I've deliberately chosen those months because by January, the newest PHP release has been around one month old, and I think it's interesting to how many early adopters there are. So let's compare first-month usage since PHP 8.1 as well:
Version | First-month usage |
8.1 | 9.1% |
8.2 | 4.7% |
8.3 | 6.4% |
8.4 | 5.1% |
PHP 8.4 isn't performing the best, but also not the worst. It makes sense that a *.1 release sees faster adoption, as it usually irons out some of the kinks of the previous *.0 release. I'm a little surprised with 8.3 taking the second place: it was a rather boring release, while 8.4 has much more exciting new features. On the other hand: boring might exactly be the reason why people are able to update more quickly.
Finally, let's bundle all data together in one big chart that starts with PHP 5.3 in 2013:
# Required versions
Besides Packagist's data, I also use Nikita's popular package analyzer to download the 1000 most popular composer packages. I use a script to scans these packages and determine their minimum required version. Here are the results:
Version | 2023-07 | 2024-01 | 2024-07 | 2025-01 |
5.2 | 7 | 7 | 5 | 5 |
5.3 | 65 | 58 | 50 | 52 |
5.4 | 31 | 28 | 26 | 26 |
5.5 | 21 | 16 | 15 | 15 |
5.6 | 32 | 30 | 29 | 31 |
7.0 | 24 | 24 | 24 | 25 |
7.1 | 125 | 100 | 93 | 101 |
7.2 | 133 | 123 | 118 | 123 |
7.3 | 56 | 49 | 42 | 45 |
7.4 | 97 | 87 | 80 | 81 |
8.0 | 144 | 126 | 123 | 128 |
8.1 | 107 | 154 | 184 | 194 |
8.2 | 94 | 135 | 153 | 171 |
8.3 | - | 0 | 4 | 4 |
8.4 | - | - | - | 0 |
There are two important notes to make here.
- This tables shows the minimum required version. That means that packages with a minimal version of, for example, 8.0, could also support PHP 8.1, PHP 8.2, PHP 8.3, and PHP 8.4.
- If you count the numbers, you'll notice there are some differences between each year. Not every package lists a valid version string.
It's easiest to visualize this data into a chart for a relative comparison, so that we can see changes over time:
Minimal PHP requirement over time
It seems that adoption rate of newer versions have slowed down, though remember that this isn't necessarily a bad thing: packages that require php: ^8.0
will automatically support PHP 8.4 as well.
On the other hand (I've made this argument many times before): I believe the PHP community would benefit overall if open source maintainers pushed more towards keeping up-to-date with the newest PHP versions. We're at a time when upgrades have never been easier thanks to automation tools like Rector; and keeping projects up-to-date with the latest PHP version only has benefits (security, performance, and newer features).
I, for one, am very excited about PHP 8.4. It's one of the most impactful releases in recent PHP history, and I really enjoy using it!