How to check PHP version

Checking the active PHP version before a deployment, extension change, or upgrade prevents one of the easiest runtime mismatches to miss. A shell session can report one interpreter while the application is actually served by a different build with older syntax support, different deprecation behavior, or a separate extension set.

Version checks in PHP are runtime-specific. The CLI binary reports the interpreter resolved in the current shell, while the web-facing runtime reports the SAPI behind the site such as apache2handler or fpm-fcgi, and each runtime can load its own configuration files and extensions.

The safest workflow is to confirm the CLI version first, then query the web-served runtime only when the site might not use the same interpreter. Hosts that mix distro packages, Homebrew, control panels, or custom builds often keep multiple binaries on one machine, so compare the reported version with the executable path and active configuration files before assuming every request is using the same PHP branch.

1. Open a terminal session on the system that runs the target PHP workload.
2. Run php -v to read the active CLI version and SAPI from the binary currently resolved in the shell.

   $ php -v
   PHP 8.5.4 (cli) (built: Mar 10 2026 23:15:23) (NTS)
   Copyright (c) The PHP Group
   Built by Homebrew
   Zend Engine v4.5.4, Copyright (c) Zend Technologies
       with Zend OPcache v8.5.4, Copyright (c), by Zend Technologies

   The first line is the decisive answer: the dotted PHP release and the cli SAPI. Build strings and loaded extension lines vary by package source.

3. Print the version, numeric version ID, and SAPI from inside the interpreter when automation or deployment checks need machine-friendly output.

   $ php -r 'printf("Version: %s\nVersion ID: %d\nSAPI: %s\n", PHP_VERSION, PHP_VERSION_ID, PHP_SAPI);'
   Version: 8.5.4
   Version ID: 80504
   SAPI: cli

   PHP_VERSION_ID is the integer form used for version comparisons, and PHP_SAPI identifies which runtime answered the command.

4. Resolve the executable path when the reported version is not the expected one.

   $ command -v php
   /opt/homebrew/bin/php

   A mismatch often means another PHP binary appears earlier in PATH than the runtime that was expected.

5. Show the active CLI configuration files when the version looks right but behavior, modules, or defaults do not.

   $ php --ini
   Configuration File (php.ini) Path: "/opt/homebrew/etc/php/8.5"
   Loaded Configuration File:         "/opt/homebrew/etc/php/8.5/php.ini"
   Scan for additional .ini files in: "/opt/homebrew/etc/php/8.5/conf.d"
   Additional .ini files parsed:      (none)

   These paths belong only to the CLI runtime that answered the command.

   Related: How to find PHP configuration files

6. Create a short-lived version probe in the document root when the web-served runtime may differ from the CLI binary.

   <?php
   header('Content-Type: text/plain');
   printf("Version: %s\n", PHP_VERSION);
   printf("Version ID: %d\n", PHP_VERSION_ID);
   printf("SAPI: %s\n", PHP_SAPI);
   ?>

   A narrow text probe keeps the check focused on version and runtime identity. phpinfo() also shows the version, but it exposes much more configuration and environment data than this job needs.

   Keep the probe temporary and place it in the same site, virtual host, or pool that serves the application. Leaving it reachable still exposes runtime details.

7. Request the probe through the web server and compare the response with the CLI result.

   $ curl -s https://portal.example.net/php-version-check.php
   Version: 8.3.6
   Version ID: 80306
   SAPI: apache2handler

   apache2handler means the site is using the Apache module. PHP-FPM deployments commonly report fpm-fcgi instead, and either value can differ from the CLI runtime.

8. Remove the temporary probe after the version is confirmed.

   $ rm /var/www/portal.example.net/public/php-version-check.php

   Leaving the probe reachable after the check exposes version and runtime details with no operational benefit.