Historically, PHP has supported both 32-bit and 64-bit environments. However, the vast majority of production deployments now use 64-bit systems. Major operating systems and distributions have either already dropped support for 32-bit architectures or are in the process of doing so. Maintaining 32-bit compatibility incurs development, testing, and ongoing maintaining overhead.
32-bit environments have known limitations especially because PHP's int type being a platform-dependent signed integer. This restricts values to a range between -2,147,483,648 and 2,147,483,647. This constraint leads to several problems:
In PHP, UNIX timestamps are defined as signed integers and used very often all over the place resulting in a limited range of 1901-12-13 20:45:52 UTC to 2038-01-19 03:14:07 UTC.
The only exception is the DateTime[Immutable] class, which internally uses int64_t, which avoids this issue.
However, using them as a workaround is risky and error-prone, especially since not all timestamp-related methods (e.g., DateTimeInterface::[get|set]Timestamp()) support full 64-bit behavior on 32-bit builds.
Additionally, other extensions rely on the UNIX timestamps as well and as such will be not fully functional (e.g. timestamps in opcache_get_status()).
On 32-bit builds, PHP can handle files up-to 2g only. This includes file streams as well.
On 32-bit builds, the PHP process is limited to 2g memory. Even on 32-bit builds on 64-bit systems resulting in mmap() failed: Cannot allocate memory + OOM Error.
Internals like opcodes, flag fields, and handlers are constrained by 32-bit word sizes, making certain optimizations or future extensions infeasible or hacky.
Most major platforms and Linux distributions have already ended support for 32-bit installations, though some still allow building and running 32-bit applications on 64-bit kernels.
| Distribution | 32-bit Support Status |
| --------------------------- | ------------------------------------------------------------------------------------ |
| Ubuntu | Dropped official 32-bit kernel and install media as of 19.10 |
| Debian | Dropped official 32-bit kernel and install media as of Debian 12 (Trixie) |
| Fedora | Dropped official 32-bit kernel and install media as of Fedora 31 |
| Arch Linux | Dropped i686 support in 2017 |
| openSUSE | Dropped 32-bit builds in Leap and Tumbleweed (Leap 15+ only supports 64-bit) |
| RHEL/CentOS/AlmaLinux/Rocky | RHEL 7 was the last version to support 32-bit; all current releases are 64-bit only |
| Windows | Dropped support for 32-bit systems as of Windows 11 |
| macOS | Dropped all 32-bit app support as of Catalina (10.15) |
| Apple Silicon | 64-bit ARM only — cannot run 32-bit code at all |
Deprecate 32-bit support in the next minor release (PHP 8.x). Completely drop 32-bit support in the next major release (PHP 9.0).
Starting with PHP 9.0, it will no longer be possible to build or run PHP on 32-bit environments.
Beginning with PHP 9.0, PHP will no longer support 32-bit builds. Attempting to compile or run PHP in such environments will fail.
This RFC makes it impossible to build or run PHP on 32-bit-only platforms starting with PHP 9.0.
Also, it will not be possible to build PHP with 32-bit on 64-bit kernels.
Is it enough to inform users about this deprecation in the documentation or should the next minor release explicitly emit deprecation warnings when running or building on 32-bit builds?
64-bit builds will remain fully supported and unaffected by this change.
This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
This requires a 2/3 majority. It is straight Yes/No vote to accepting the RFC.
Links to any external patches and tests go here.
If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.
Make it clear if the patch is intended to be the final patch, or is just a prototype.
For changes affecting the core language, you should also provide a patch for the language specification.
After the project is implemented, this section should contain
Links to external references, discussions or RFCs
Keep this updated with features that were discussed on the mail lists.