Is PHP Dead? Why PHP Is Still a Solid Choice Today
Is PHP dead? No. What modern PHP looks like, where it still runs, its real weak spots, and what it means if your business runs on PHP today.

Freelance full-stack developer
- Published
- Reading time
- 12 min
In this post8
Is PHP dead? No. PHP still powers close to 70% of websites whose server-side language can be detected, and it ships a new release every year with four years of support. What has died is the PHP many people remember from the early 2000s: loose scripts with no structure, no types and no tests.
I build with PHP and Laravel every day as a freelance developer, so factor in my bias. That's also why this post covers the weak spots and the projects where I'd reach for something else.
The short answer
| Claim | Reality |
|---|---|
| "Nobody uses PHP anymore" | Roughly 70% of websites with a known server-side language run PHP (W3Techs, October 2026) |
| "PHP is slow" | PHP 7 was up to twice as fast as PHP 5.6, and PHP 8 added a JIT compiler on top |
| "PHP is insecure" | Security depends on the version and the code. Each release gets security fixes for four years |
| "PHP code is a mess" | Modern PHP has types, a package manager and shared coding standards. Messy code can be written in any language |
| "You can't hire PHP developers" | Nearly one in five developers worked with PHP in the past year, according to Stack Overflow (2025) |
My rule of thumb: if your system runs on a PHP version that still receives security updates, and another developer can work in the code, you don't have a PHP problem. If you're on an old version, or only one person understands the code, you have a maintenance problem. Switching languages rarely fixes that.
The language is one decision among many. For the bigger picture, see my walkthrough of how a software development project runs from idea to launch. If you're unsure how language, framework, database and hosting fit together, I've also explained what a tech stack is in plain English.
Why people keep asking if PHP is dead
Three things keep the question alive.
The first is history. PHP took off around 2000 because it was easy to get started with. A lot of early sites mixed HTML, database queries and business logic in the same file. The result was code that was hard to maintain and easy to attack, with SQL injection as the classic example. The reputation stuck long after the language moved on.
The second is fashion. New developers usually learn JavaScript or Python first, and most new courses and tools are built around them. In Stack Overflow's 2025 Developer Survey, 18.9% of respondents said they had worked with PHP in the past year, against 66% for JavaScript and 57.9% for Python. PHP isn't what developers talk about most, and that's a fair point.
The third is that "X is dead" gets clicks. The same article has been written about Java and WordPress for years.
But developer buzz and real-world use are different things. According to W3Techs, PHP runs on 69.8% of websites whose server-side language it can identify (October 2026). WordPress explains much of that, powering around 40% of all websites on its own. Wikipedia runs on PHP too, and frameworks like Laravel and Symfony are used for web apps, customer portals and SaaS products. A language that runs that much of the web isn't going anywhere soon.
Modern PHP is not the PHP you remember
If you last looked at PHP code a decade ago, what gets written today will look unfamiliar. For a business, the syntax matters less than what it means for bugs, speed and maintenance costs.
Types catch bugs before your users do
Modern PHP lets developers declare exactly what kind of data a function accepts and returns. PHP 8.1 added enums (fixed lists of values, such as an order status) and readonly properties, so data can't be changed by accident. PHP 8.4 added finer control over which parts of the code may read or change data, and PHP 8.5 brought, among other things, a built-in, standards-based way to parse and handle URLs.
Combined with static analysis tools that check code before it runs, more mistakes get caught by the developer instead of by your customers.
Speed is rarely the bottleneck
According to the PHP project, PHP 7 was up to twice as fast as PHP 5.6. PHP 8 introduced a JIT compiler (an engine that turns code into machine code while it runs), which was rebuilt in PHP 8.4. In the web apps I work on, slowness almost always comes from inefficient database queries, missing caching or heavy tasks that should run in the background. Those problems look the same in any language.
An ecosystem, and a foundation behind it
Composer, PHP's package manager, lets developers pull in maintained libraries instead of copying code in by hand. Frameworks like Laravel and Symfony give you proven structure for authentication, databases, background jobs and testing. I've written up why Laravel is my default for web apps in a separate post.
PHP also doesn't rest on a handful of volunteers. The PHP Foundation, launched in 2021, pays a team of developers to work on maintenance, security and new features. Its sponsors include JetBrains, Automattic (the company behind WordPress.com) and Germany's Sovereign Tech Agency. On top of that, the release schedule is predictable: a new version every year, usually in November, with two years of active support followed by two years of security fixes.
What it means if your business runs on PHP
PHP being alive doesn't mean your PHP system is healthy. What counts is which version it runs and how well the code has been looked after.
According to the official list of supported PHP versions, each release gets bug fixes for two years and then critical security fixes only for two more. After that it reaches end of life: no fixes at all, even when a new vulnerability becomes public.
| PHP version | Released | Security fixes until |
|---|---|---|
| 5.6 | 2014 | Dec 31, 2018 |
| 7.4 | 2019 | Nov 28, 2022 |
| 8.0 | 2020 | Nov 26, 2023 |
| 8.1 | 2021 | Dec 31, 2025 |
| 8.2 | 2022 | Dec 31, 2026 |
| 8.3 | 2023 | Dec 31, 2027 |
| 8.4 | 2024 | Dec 31, 2028 |
| 8.5 | 2025 | Dec 31, 2029 |
The real-world picture isn't pretty. W3Techs reports that 27.7% of the PHP sites it tracks still run PHP 7, and 7.8% run PHP 5 (October 2026). None of those versions get security updates from the PHP project anymore. Add the sites on PHP 8.0 or 8.1, and roughly half of all PHP sites run a version with no support. Count PHP 8.2 as well, which reached end of life at the end of 2026, and it's about two thirds.
For a business in the EU, an outdated version usually means three things:
- Known vulnerabilities stay open. If the system processes personal data, that's hard to square with the GDPR's requirement for appropriate technical security measures (Article 32).
- Hosting becomes a headache. Many hosting providers phase out old PHP versions, which can leave you with a system that's hard to move.
- New packages and framework versions require newer PHP, so every new feature costs more to build.
None of this means the system has to go. Rewriting in another language because PHP sounds dated is rarely a good investment. You pay to rebuild what you already have, and you risk losing business rules that only exist in the old code. The problem is almost always the version and the state of the code, not the language. I've written about what technical debt costs when cleanup keeps getting postponed.
How to audit your PHP system in 5 steps
You don't need to be a developer to get an overview. These are the same steps I go through when I'm handed access to an existing PHP codebase.
- Find the PHP version. It's usually shown in your hosting control panel, or your developer can check it in a minute. Compare it with the table above or the official list of supported versions.
- Find out what the system is built on. Is it WordPress, Laravel, Symfony, an older framework like CodeIgniter, or custom code? Frameworks have their own support windows, and a homegrown foundation is much harder for a new developer to take over.
- Check the dependencies. If the project uses Composer, a developer can run
composer auditto check the installed packages against known security advisories. No Composer usually means third-party code was copied in by hand, which makes it harder to keep current. - Find out who can work on the code. Do you have access to the repository, and are there tests and documentation? If only one person can make changes, that's a bigger risk than the language itself.
- Pick a plan. A version that's slightly behind needs routine upgrades. One that's far behind can usually be modernized step by step, so a full rewrite is rarely the only option. I've covered the signs that a legacy PHP system needs modernizing and what that process looks like.
Checklist: is your PHP system healthy?
- Supported version: the system runs on a PHP version that still receives security fixes.
- Known foundation: the code is built on a maintained framework or CMS, not on homegrown code nobody else knows.
- Current dependencies: packages are managed with Composer, with no known security advisories.
- Access to the code: you own the repository and hosting accounts and can log in yourself.
- More than one person: another developer could get up to speed without starting over.
- Tests: the critical flows, such as login and payments, are covered by automated tests.
- A plan: time and budget are set aside for upgrades at least once a year.
When PHP is the wrong choice
PHP is my default for web apps with users, data and business rules. It isn't the answer to everything, though, and in these cases I'd usually pick something else:
- Machine learning and heavy data processing. Python has the strongest ecosystem for that work. If the app also has users and business logic, a PHP app can call a Python service.
- Apps where nearly everything happens in the browser and the server only stores a little data. JavaScript or TypeScript can be simpler here. If that's the decision in front of you, see my comparison of Laravel and Next.js.
- A team that already runs .NET, Java or Node. Adding a new language because one new developer prefers it rarely pays off.
- Mobile apps. PHP works well as the backend and API behind an app, but the app itself is built with other tools.
There are also cases where you don't need a developer like me. If your system is a WordPress site that mainly needs plugin and PHP updates, a WordPress specialist or a managed host is often cheaper. And if the system runs on a supported version, works, and you have no new requirements, leave it alone and keep the updates coming.
Next steps
PHP isn't dead, but outdated PHP versions are a real risk. Start by finding out which version your system runs and who can work on the code. It rarely takes more than a quick conversation with your developer or hosting provider, and then you know whether there's work ahead of you or not.
If you're building something new, PHP with a modern framework is still a safe choice for web apps, customer portals and SaaS products. On my Laravel development page you can see how I work on both new builds and existing PHP systems: a paid, fixed-price discovery phase before larger projects, direct contact with the developer writing the code, and code you own from day one. I work from Denmark, on Central European Time.
Frequently asked questions
Is it hard to hire PHP developers?
No, PHP is still one of the most widely used languages on the web, so there are plenty of developers who know it. The hard part is finding someone who writes modern PHP and is also willing to take over old, homegrown code with no framework. The more closely a system follows a well-known framework like Laravel or Symfony, the larger the pool of developers who can find their way around it quickly.
What's the difference between PHP and Laravel?
PHP is the programming language, and Laravel is a framework written in PHP. The framework provides ready-made building blocks for authentication, databases, email and background jobs, plus a fixed structure for where code lives. You can write PHP without a framework, but for web apps and customer portals I almost always use one, because the code becomes easier to maintain and hand over.
How long does a PHP upgrade take?
It depends mostly on how far behind the system is and how the code was written. Moving between two recent PHP 8 versions in a well-kept project is often a small job. Jumping from PHP 5 to PHP 8 in custom code with no tests is a project in its own right. Start with a code review so you have an estimate before you commit to anything.
Is WordPress built on PHP?
Yes, WordPress is written in PHP, so everything in this post applies to WordPress sites too. The PHP version is usually set by your hosting provider, and it has to work with WordPress itself, your theme and your plugins. An old plugin that breaks on newer PHP is one of the most common reasons a WordPress site gets stuck on an end-of-life version.
Does an end-of-life PHP version break GDPR compliance?
Not automatically. The GDPR doesn't mention software versions, but it does require security that is appropriate to the risk, and software that no longer receives security fixes makes that harder to defend. This matters most for systems holding customer, payment or health data. If you're in that position, document the risk and a plan to fix it, and check the details with your data protection officer or a legal adviser.