PHP Version Checker Online

Last updated: What’s new

Check whether a website publicly exposes a PHP version. See the exact signal, the URL and response tested, evidence strength, lifecycle context, and what to verify next.

No signup required. Technical scan results may be used to produce aggregate website statistics. Research records do not include your name, email, IP address, or analytics ID. Privacy details

Paste a public URL to check whether its response exposes a PHP version:

How the Online PHP Version Checker Works

This tool checks public response signals for an exact PHP/version token. It cannot inspect the private runtime configuration. Here's the process:

  1. Submit the page you care about. The checker keeps that path and may try its HTTP/HTTPS and www/non-www variants, skipping any that redirect to a response it already inspected. It does not probe admin pages or other common paths, except one request to the WordPress REST API root when the page declares WordPress and hides the version.
  2. Inspect bounded public evidence. It sends HEAD, then GET when needed, checks X-Powered-By and Server, and reads at most the first 512 KB of the response body.
  3. Review the evidence. The result shows the exact signal, request method, HTTP status, response URL, support phase, and limitations. A body mention is explicitly not treated as runtime proof.
  4. Get context when the version is hidden. If the page declares a PHP application such as WordPress or Drupal, the result names it and its official minimum PHP version where one is published. That is context, not the PHP version serving the URL.

"Not detectable" means the checked responses did not expose a supported signal. It does not mean the website is not using PHP.

Why Check Your PHP Version?

PHP powers WordPress, WooCommerce, Drupal, Laravel, and many custom applications, but well-configured production sites commonly hide runtime version headers. This check is most useful as a quick external observation or a way to spot accidental version disclosure.

PHP's official lifecycle separates active support, security-fixes-only support, and end of life. The PHP project urges users of unsupported branches to upgrade because later releases may contain security and bug fixes they do not receive. A version signal alone does not establish whether the site is patched, secure, or compatible with a newer branch. Run a security headers check for a separate set of public HTTP observations.

If you plan to change PHP, measure your own application before and after on production-like staging. Runtime performance depends on the application, extensions, cache, database, server configuration, and workload. Use our performance checker for public page measurements, not as a substitute for server-side profiling.

If you're running a WordPress site, we've written detailed guides on which PHP version to use and which PHP extensions WordPress needs. You can also inspect publicly exposed WordPress version clues, use the WordPress Theme & Plugin Detector to review visible theme and plugin evidence, or check a site's public technology signals for a broader external inventory.

Setting up or hardening a WordPress install? Our wp-config.php generator builds a secure configuration baseline, and the WP REST API exposure checker flags whether your site is leaking user data through the REST API.

Tired of chasing PHP versions altogether? A static Astro website has no PHP, no plugins, and no database to maintain, just clean HTML that loads in under a second and is easy for AI engines to cite. If you're on WordPress, our WordPress to Astro migration services include URL mapping, redirect checks and post-launch monitoring.

PHP Version Support Timeline

The lifecycle below reflects PHP's official supported-versions and end-of-life tables as of 2 October 2026. It avoids volatile point-release and CVE totals; use the linked PHP sources for current release notices and security information.

PHP branch support status as of 2 October 2026
Branch Status Active support until Security support until
PHP 8.0 End of life 26 Nov 2022 26 Nov 2023
PHP 8.1 End of life 25 Nov 2023 31 Dec 2025
PHP 8.2 Security fixes only 31 Dec 2024 31 Dec 2026
PHP 8.3 Security fixes only 31 Dec 2025 31 Dec 2027
PHP 8.4 Active support 31 Dec 2026 31 Dec 2028
PHP 8.5 Active support 31 Dec 2027 31 Dec 2029

Active support means regular bug and security fixes. Security support means critical security fixes only, released as needed. After end of life, the PHP project publishes no more fixes for that branch. Sources: PHP supported versions and unsupported branches.

PHP 8.0 and 8.1 are unsupported, while 8.2 and 8.3 receive critical security fixes only. Do not select a target branch from this table alone. For WordPress, review our recommended PHP version guidance and test the exact site on staging.

How to Check the PHP Version in WordPress

WordPress reports the PHP version it runs on in Site Health:

  1. Log in to the WordPress dashboard as an administrator.
  2. Open Tools → Site Health.
  3. Select the Info tab.
  4. Expand the Server section and read the PHP version row.

WordPress documents Site Health as the dashboard view for server and PHP configuration information. Without dashboard access, this checker reads the page's public headers and body and, when a WordPress page hides the version, the site's REST API root. If both hide it, the result names WordPress and, where the WordPress version is visible, the minimum PHP that version needs.

How to Verify the PHP Version You Actually Control

Use this public checker as a lead, then confirm the environment that serves the application:

  • cPanel or another host panel: inspect the PHP selector or domain runtime setting for the exact production domain. A server-wide default may differ from a site-specific setting.
  • A one-line PHP file: upload a file containing only <?php echo PHP_VERSION;, open it once in the browser, then delete it. It shows the web runtime and discloses far less than phpinfo().
  • WP-CLI: wp --info reports the PHP binary WP-CLI uses, which can differ from the one serving web requests.
  • Command line: run php -v to identify the CLI SAPI. PHP documents CLI as a separate SAPI, so do not assume that its binary or configuration matches PHP-FPM, Apache, or another web SAPI.
  • Production and staging: check both. Also confirm scheduled jobs and workers when they use separate commands or containers.

Need to answer "will my WordPress site work after the change?" This detector cannot answer that. Use the WordPress PHP Upgrade Readiness Checker to inventory core, theme, plugin, and custom-code evidence, then run its staging test plan.

Primary references: PHP's command-line SAPI documentation and -v option reference.

Which PHP Version Does Each Method Verify?

MethodEvidenceLimit
Public header or body clueA token exposed by one public responseMay be stale, hidden or supplied by a proxy. It does not prove every runtime.
WordPress Site Health or hosting panelAuthenticated application or domain configuration evidenceCheck the correct domain and environment, including staging.
Shell php -vThe CLI binary selected on that shellThe web server or PHP-FPM pool can use a different version and configuration.

For PHP 8.2 planning, use the PHP 8.2 end-of-life guide and the WordPress upgrade readiness checker before changing the runtime.

What’s new

  • Recent results can be reopened without another DNS lookup. When a check has to wait, the checker gives a time to retry.

  • Long evidence values expand on request while the diagnosis, security comparison and host message remain visible.

  • Results now compare a reported PHP branch, or a hidden version, with our PHP2Shell study of 112,163 sites, where 19,620 showed a clear PHP version.

Next steps

Online PHP Version Checker related tools and articles

Continue with the closest follow-up checks and guides based on this tool's topic, crawl intent, and optimization workflow.

PHP Version Checker: FAQ

Which public signals does the PHP checker use?
It looks for an exact PHP/version token in X-Powered-By, then Server, then the first 512 KB of a GET response body. X-Powered-By is labelled strong public-header evidence, Server is moderate, and a body mention is low-confidence context rather than proof of the runtime.
How can I tell if a website uses PHP?
Run this checker on the site. It reports a PHP version token in the X-Powered-By or Server header or the page body, and when the version is hidden it names PHP applications it finds clues for, such as WordPress, Drupal, Joomla, Laravel or Magento, or a PHPSESSID session cookie. Finding none of these does not mean the site has no PHP, because many sites hide every clue.
Which PHP version is my WordPress site using?
In the WordPress dashboard, open Tools → Site Health → Info and expand Server: the PHP version row shows the version WordPress runs on. From outside, this checker shows a version only when the site exposes one in a page or REST API response; when both hide it, the result names WordPress and, where the WordPress version is visible, the minimum PHP it needs.
How do I check the PHP version from the command line?
Run php -v in Terminal, Command Prompt or an SSH session. A "command not found" or "not recognized" message means no PHP command-line binary is on your PATH. The CLI version can differ from the one serving your website, so confirm the web runtime in your hosting panel or Site Health.
Why does the result say Not detectable?
Most production sites hide runtime versions, and a CDN, proxy, cache, or security layer can strip them. The site may also use a different runtime. Not detectable means no supported public signal was found, not that PHP is missing or unsafe.
What do confidence and evidence mean?
The evidence label describes where the exact token appeared; it is not a probability. Even a strong X-Powered-By header is a public claim for one response and does not prove which PHP binary handles every route, worker, cron job, or server behind a proxy or load balancer.
Can a detected version be stale or misleading?
Yes. A proxy can expose an old header, a cached page can contain a version string, and body text can mention PHP without identifying the runtime. Treat moderate and low-confidence results as leads, and verify even strong header evidence before making an upgrade decision.
How should I verify the version on a site I own?
For WordPress, use Tools, Site Health, Info, Server. In cPanel or another hosting panel, check the PHP selector for the exact domain. On a shell, php -v identifies the CLI runtime only; PHP's CLI and web server SAPIs can use different binaries or configuration, so confirm the web runtime separately. Check production and staging independently.
Does this PHP version detector test WordPress compatibility?
No. It checks only public version signals. It does not inspect WordPress core, themes, plugins, extensions, custom code, or staging behavior. Use the WordPress PHP Upgrade Readiness Checker to inventory compatibility evidence and build a test plan before changing PHP.
What should I do if the verified version is unsupported?
Back up the site, clone or use staging, check CMS, theme, plugin, extension, and custom-code compatibility, then upgrade and test critical pages, forms, checkout, jobs, and integrations. Keep a documented rollback path.
Why might a repeated check show a cached result?
Results are cached in server memory for 10 minutes by normalized URL, and the response indicates whether it was cached. Serverless instances may not share that memory, so caching behavior can vary. Wait or verify directly when testing a recent server change.
What data is sent and retained by this checker?
The submitted public URL is sent to Web Aloha's server, which may try HTTP, HTTPS, www, and non-www variants of that exact path with HEAD and GET requests, plus one request to the WordPress REST API root when the page declares WordPress and hides the version. The normalized URL and result can remain in an in-memory cache for up to 10 minutes. When research collection is enabled, limited technical results may also be used for research for up to 90 days to produce aggregate website statistics, then removed by daily cleanup. Research records use coded website and page keys, without raw URLs, page bodies, raw headers, names, email addresses, visitor IP addresses, or analytics IDs. Ordinary hosting and analytics processing is described in our Privacy Policy.