Introduction

The location of php.ini depends on how PHP was installed and which SAPI you are using. A command-line PHP binary, Apache module, and PHP-FPM pool can all load different configuration files, so the right answer is not "here is one universal path." The reliable approach is to ask the PHP runtime directly.

The Fastest Way to Find the Loaded File

For command-line PHP, the quickest check is:

php --ini

That command usually shows:

• the main loaded configuration file
• the directory scanned for extra .ini files
• any additional configuration files that were loaded

If you only want the specific main file, this also works:

php -i | grep "Loaded Configuration File"

If the output says (none), PHP may be running with built-in defaults or it may be scanning only additional configuration directories.

Web Server PHP Can Use a Different php.ini

A common source of confusion is that the web server may use a different PHP runtime than the one you get from your shell.

For example:

• 'php in the terminal might point to one installation'
• Apache with mod_php might load another configuration
• PHP-FPM might use a separate pool and separate config layout

That is why php --ini is authoritative for CLI, but not necessarily for a web request.

For a web-served check, create a temporary script:

<?php
phpinfo();

Open it in the browser and look for Loaded Configuration File. That tells you which php.ini the web-executed PHP process is using.

Remove the file afterward. phpinfo() exposes a lot of server detail and should not be left accessible on a public environment.

Common Default Locations

Although you should verify with the runtime, there are common patterns:

• Linux package installs often use paths such as /etc/php.ini or /etc/php/8.2/cli/php.ini
• Apache and PHP-FPM builds on Debian or Ubuntu often split config by SAPI, such as /etc/php/8.2/apache2/php.ini and /etc/php/8.2/fpm/php.ini
• XAMPP on Windows commonly uses a path such as C:\xampp\php\php.ini
• Homebrew on macOS often places config under a versioned etc directory

These examples are useful hints, but they are not substitutes for checking the active runtime.

Additional .ini Files Matter Too

Many setups do not put all PHP settings in one file. The main php.ini can be extended by a directory of extra config fragments.

That is why php --ini is more helpful than guessing the main file path. It can show both:

• the primary config file
• extra files such as extension or environment overrides

For example, you might edit the right php.ini and still see no change because another later-loaded file overrides the directive.

After Editing, Restart the Right Service

Changing php.ini does not always take effect immediately. The relevant process may need a restart.

Typical commands look like this:

sudo systemctl restart apache2
sudo systemctl restart php8.2-fpm

Restart the component that actually runs your PHP code. Restarting Nginx alone does not reload PHP-FPM configuration unless PHP-FPM itself is also restarted.

For CLI testing, simply running php again is usually enough because each CLI invocation starts a fresh process.

Common Pitfalls

The most common mistake is editing the CLI php.ini and expecting a web application to change. Different SAPIs often have different config files.

Another mistake is looking only for the main php.ini and ignoring extra scanned .ini files that may override the setting you changed.

A third pitfall is leaving a phpinfo() page deployed after debugging. It is convenient, but it reveals too much environment information.

Summary

• Use php --ini to find the CLI configuration file and scanned .ini directories.
• Use a temporary phpinfo() page to see which config file the web runtime is loading.
• Do not assume the CLI, Apache, and PHP-FPM all use the same php.ini.
• Check additional .ini files because later overrides can hide your change.
• Restart the correct PHP-serving process after editing configuration.