PHP still runs on 32-bit systems, even though most servers today are 64-bit. This RFC from Marc Bennewitz would deprecate 32-bit builds in the next PHP 8.x release and drop them entirely in PHP 9.0.

Why change it

Keeping 32-bit support working takes ongoing effort, since someone has to build it, test it and fix it.

On a 32-bit build, a PHP int only ranges from about -2.1 billion to 2.1 billion, and that limit causes real problems:

  • The year 2038 problem. Timestamps are stored as an int, and on 32-bit they run out on January 19, 2038. That affects date(), time(), file times like filemtime(), and cache expiry times.
  • File size. PHP can only handle files up to 2 GB.
  • Memory. A PHP process can only use 2 GB of memory.
  • Odd results. crc32() and ip2long() often return negative numbers.

DateTime and IntlCalendar store time differently, so they get past the 2038 limit. The RFC still calls relying on them risky, since their timestamp methods return a PHP int.

Most operating systems have also moved on. The RFC lists Ubuntu, Debian, Fedora, Arch, openSUSE, RHEL, Windows 11 and macOS as having dropped 32-bit installs or apps, and Apple Silicon can't run 32-bit code at all.

What the RFC would do

  • Next PHP 8.x: 32-bit support is deprecated, and deprecation notices are optional.
  • PHP 9.0: you can no longer build or run PHP on 32-bit systems, and you can't build a 32-bit PHP on a 64-bit system either.

One question is still open: is a note in the documentation enough, or should PHP show a warning when it's built or run on 32-bit?

What it means for you

If you run PHP on 64-bit, nothing changes. If you still run it on a 32-bit system, you'd need to move to 64-bit before PHP 9.0.

Where it stands

The RFC is under discussion and was first posted on June 18, 2025. There's a pull request to deprecate 32-bit builds, but no vote has been set up yet. It would need a two-thirds majority to pass.

We list it as inactive because the page hasn't changed since June 2025 and no vote was ever held.