Before you can run a single line of PHP, you need an interpreter on your machine. How you get one depends entirely on your operating system, and the path you choose has real consequences later — a bare interpreter is enough to run scripts from the command line, but web development also needs a web server and, usually, a database, which is why bundled stacks exist. This page covers installing PHP itself on Windows, macOS, and Linux, confirming the install worked, finding the configuration file that controls PHP's behavior, and managing more than one PHP version on the same machine.

Windows has no PHP interpreter built in, so you have two realistic options. The first is installing PHP directly from the official binaries at windows.php.net: download the "Non Thread Safe" zip if you will run PHP only through PHP-FPM or the CLI, or the "Thread Safe" build if you plan to use it as an Apache module. Unzip it somewhere permanent (for example C:\php) and add that folder to your PATH environment variable so php is available from any terminal.

The second option — and the one most beginners should reach for first — is installing a bundled stack such as XAMPP, which ships Apache, PHP, and MySQL/MariaDB preconfigured and wired together with a control panel. It trades some control over exact versions for a much faster path to "it works." A dedicated XAMPP setup tutorial covers that installer in detail; use the manual zip approach above when you specifically need a particular PHP version or want to pair PHP with a web server you already have installed.

macOS ships with an Apple-provided PHP binary on some older versions, but it is frequently missing, outdated, or removed entirely on recent releases — do not rely on it. The standard approach is Homebrew, the package manager most Mac developers already use for command-line tools.

On Debian-based distributions, PHP is available directly from the default package repositories through apt. Refreshing the package index first ensures you get a current version rather than a stale cached listing.

Other distributions follow the same idea with their own package manager — dnf install php on Fedora, pacman -S php on Arch — the package name is consistently just php.

Regardless of platform, two commands confirm PHP is installed and tell you what it can do. php -v prints the interpreter's version and build information; php -m lists every extension (module) currently compiled in or loaded, which matters because a lot of "this library doesn't work" issues turn out to be a missing extension like mbstring, curl, or pdo_mysql.

If php is "not recognized" or "command not found," the interpreter either failed to install or was not added to your shell's PATH — on Windows this is almost always the missing PATH entry from the step above; on macOS/Linux it usually means the shell session was opened before the install finished and needs to be restarted.

PHP reads its settings from a file called php.ini at startup — error reporting level, upload size limits, timezone, which extensions load, and dozens of other behaviors all live there. The exact file location varies by OS and by whether you are running the CLI or a web server SAPI (a machine can have a separate php.ini for each). php --ini tells you exactly which file is in use and where PHP looked for others.

Sooner or later you will work on two projects that require different PHP versions — one legacy codebase pinned to PHP 7.4, another built against PHP 8.3 features. Overwriting a single system-wide PHP every time you switch projects does not scale, so version managers exist to keep several installs side by side and let you pick which one is active.