What Is PHP?

What PHP is

PHP is an open-source, general-purpose scripting language that was designed for building web pages and is still used mostly for that. The name is a recursive acronym: PHP: Hypertext Preprocessor. A PHP program runs on a server, produces text (an HTML page, a JSON answer for an API, a CSV export) and sends that text to whoever asked for it. As of October 2026, W3Techs counts PHP as the server-side language of 69.8% of the websites whose server-side language it can detect — largely because WordPress, which runs about 40% of all websites, is written in PHP.

A few properties shape how the language feels:

• Interpreted, with no build step. You save a .php file and run it; PHP translates it while running. See scripting languages.
• Dynamically typed, with optional type checks. A variable can hold any type of value, but functions can declare the types they accept, and PHP enforces them. See Variables, Types and Type Juggling.
• Made for the request–response cycle. Reading form fields, setting cookies and sending headers are built into the language rather than added through a framework (see PHP and the Web).
• Multi-paradigm. Plain step-by-step scripts, functions, and full object-oriented code with classes, interfaces and enums all work, and real projects mix them.

Here is a complete PHP program. It works out the average of some meter readings and prints two lines:

<?php
// Daily electricity use (kWh) of one household, from a smart meter
$readings = [11.2, 9.8, 12.5, 10.1, 13.4];

$total = 0;
foreach ($readings as $kwh) {
    $total = $total + $kwh;
}

$average = $total / count($readings);
echo "Days measured: " . count($readings) . "\n";
echo "Average per day: " . number_format($average, 1) . " kWh\n";

Days measured: 5
Average per day: 11.4 kWh

The file starts with the opening tag <?php. Variable names start with $, statements end with a semicolon, braces mark blocks, // starts a comment, echo prints text and the dot (.) glues strings together. The next page, Running PHP, shows how to run a file like this.

Server-side scripting

Server-side scripting means that a program on the web server builds the response for each request, instead of the server sending a file that already exists. The browser receives only the result. That is the key difference with client-side JavaScript, which is downloaded and runs on the visitor's device: PHP code, database passwords and business rules stay on the server.

PHP was born as a template language: a .php file can be mostly HTML with small pieces of PHP in it. Everything outside the tags <?php … ?> is sent as it is; <?= … ?> is a short form of <?php echo … ?>. This file builds a small page:

<?php
$customer = "J. de Groot";
$outages = ["Deventer", "Zwolle"];
?>
<h1>Planned outages</h1>
<p>Hello, <?= htmlspecialchars($customer) ?>.</p>
<ul>
<?php foreach ($outages as $town): ?>
  <li><?= htmlspecialchars($town) ?></li>
<?php endforeach; ?>
</ul>

<h1>Planned outages</h1>
<p>Hello, J. de Groot.</p>
<ul>
  <li>Deventer</li>
  <li>Zwolle</li>
</ul>

Two details are worth noticing. The browser gets plain HTML with no trace of the loop. And every value is passed through htmlspecialchars() before it goes into the page, so a name that contains <script> is shown as text instead of being run as code — the standard defense against cross-site scripting, explained in PHP and the Web. The foreach (…): … endforeach; form of the loop is meant for templates like this one; see Control Flow and Loops.

A short history

In 1994 Rasmus Lerdorf wrote a set of small C programs to track visits to his online CV and called them "Personal Home Page Tools". He released the source code in June 1995, and other people started to use and extend it. The milestones since then:

PHP has no company that owns it. The language is developed in the open by volunteers and paid core developers; new features are proposed as RFCs (requests for comments) on wiki.php.net and voted on. Since 2021 The PHP Foundation, founded by companies that depend on PHP (among them JetBrains, Automattic, Laravel, Symfony and Zend), pays several core developers.

How PHP runs code

The Zend Engine is the core of PHP: the part that compiles PHP source code and executes it, manages memory and provides the basic types. Its name combines the first names of its authors, Zeev and Andi. Running a script happens in two steps:

1. The engine reads the file and compiles it to opcodes, small instructions for PHP's virtual machine — PHP's form of bytecode.
2. The engine's executor runs those opcodes one by one. Functions such as strlen() or json_encode() are written in C and come from the core or from extensions.

Compiling the same files for every request would be wasteful, so production servers use OPcache, which keeps the compiled opcodes in shared memory. PHP 8 also has a just-in-time (JIT) compiler that turns hot code into machine code, but it is off by default and helps mostly with heavy calculations, not typical web pages that wait on a database. Both are covered in Deploying PHP.

A clean slate for every request

In the classic setup, each request runs the script from the top, with no variables, objects or open connections left over from the previous request. When the response is sent, everything the script created in memory is thrown away. This is often called a shared-nothing design.

It has real advantages: a bug or a memory leak in one request cannot spill over into the next, and you can add servers without them needing to share memory. The price is that anything that must last — a shopping cart, a login — has to be stored outside the script: in a database, a file, a cache or a session. (Newer application servers such as FrankenPHP can keep an application loaded between requests in a "worker mode"; that is an option, not the default.)

From request to response

PHP does not usually accept connections from browsers itself. A web server sits in front: it handles the connection and TLS, serves images and CSS files directly, and hands every request for a .php URL to PHP. The two common ways to connect them:

• PHP-FPM (FastCGI Process Manager): a separate service with a pool of PHP worker processes. Nginx, Apache or Caddy forwards each request to it over the FastCGI protocol. This is the usual setup today.
• mod_php: PHP loaded as a module inside the Apache web server itself. Simple and still common on older and shared hosting.

On the wire, a request and the response PHP built look like this:

GET /outages.php?area=Deventer HTTP/1.1
Host: portal.example.com
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<h1>Planned outages</h1>
…

Nothing in the response tells the browser that PHP was involved. The way PHP connects to the server is called its SAPI (Server Application Programming Interface): fpm-fcgi, apache2handler for mod_php, or cli on the command line. The full request cycle is in HTTP in Depth; the server side in Deploying PHP.

PHP on the command line

PHP is not limited to web pages. The php command runs a script in a terminal, just like python3 or node:

php average.php       # run a script
php --version         # which PHP is installed

Days measured: 5
Average per day: 11.4 kWh
PHP 8.4.26 (cli) (built: …) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.26, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies

Command-line PHP is used for scheduled jobs (a nightly import of meter readings started by cron), queue workers, database migrations and the tools themselves: Composer, PHPUnit and WordPress's WP-CLI are all PHP programs. The examples on this site are command-line scripts too. Details, the interactive shell and a development web server are in Running PHP.

Versions and support

PHP version numbers have three parts: 8.4.26 is major version 8, minor version 4 (the branch), patch release 26. A new minor version comes out every year, usually in late November or early December; patch releases with bug and security fixes come roughly every month. New major versions are rare and mean that old code may need changes.

PHP version support is the fixed life cycle every branch goes through: two years of active support (bugs and security issues are fixed), then two years of security support (only security fixes, released when needed), then end of life: no more fixes at all, even for known vulnerabilities.

PHP 8.6 is scheduled for 19 November 2026 (release candidates are out as of October 2026). No date has been set for a PHP 9. The current table is always on php.net/supported-versions.php.

Dates in ISO format compare correctly as plain strings, so a few lines of PHP can work out the status of each branch on a given day:

<?php
// End of active support and of security fixes per branch (php.net)
$support = [
    '8.5' => ['2027-12-31', '2029-12-31'],
    '8.4' => ['2026-12-31', '2028-12-31'],
    '8.3' => ['2025-12-31', '2027-12-31'],
    '8.2' => ['2024-12-31', '2026-12-31'],
];
$today = '2026-10-02';

foreach ($support as $branch => [$activeUntil, $securityUntil]) {
    if ($today <= $activeUntil) {
        $status = 'active support';
    } elseif ($today <= $securityUntil) {
        $status = 'security fixes only';
    } else {
        $status = 'end of life';
    }
    echo "PHP $branch: $status\n";
}

PHP 8.5: active support
PHP 8.4: active support
PHP 8.3: security fixes only
PHP 8.2: security fixes only

Where PHP is used

• Content management systems — WordPress (7.1 as of October 2026), Drupal, Joomla and many shops and forums. A lot of PHP work in operations is keeping such sites updated.
• Web applications and APIs — built with a framework such as Laravel (13, March 2026) or Symfony (8.1, with 7.4 as the long-term support version), or with plain PHP for small internal tools.
• Command-line tools and jobs — imports, exports, reports and queue workers.

Reusable code is shared as packages through Composer and its public registry, Packagist, which lists about 470,000 packages as of October 2026. Coding standards and testing tools are covered in Modern PHP: Versions, Standards and Testing.