Where Is the php.ini File in WordPress? How to Find and Edit It

Where is the php.ini file in WordPress, and why is it missing from your site folder? WordPress does not ship one, because php.ini belongs to the PHP install on your server. The quickest way to find its path is a temporary phpinfo page that prints the loaded file.

We checked every step in this guide in October 2026 on a WordPress 7.1.3 test site running PHP 8.5. We also read the PHP manual, the WordPress developer docs and the cPanel docs for each claim.

Below you will find three ways to locate the file and what to do on shared hosting or a VPS. You will also learn how to raise the upload and memory limits safely, and why a change sometimes does not show up.

Where Is the php.ini File in WordPress?

Where is the php.ini file in WordPress? It is on your server, outside the WordPress folders, and PHP reads it at startup. Your host controls the path, which a phpinfo page shows, and shared hosting usually offers a control panel screen instead.

That file matters because it holds the limits PHP puts on every WordPress request. These are the four most people look for, with the defaults from the PHP manual:

Setting	PHP default	What it limits
memory_limit	128M	Memory one script can use
upload_max_filesize	2M	Size of one uploaded file
post_max_size	8M	Size of all data in one form submission
max_execution_time	30	Seconds a script may run

A host can ship different values. The numbers on your site may not match this table. Our test site started with these exact defaults for upload size, and the Site Health screen reported them back.

If you see “The uploaded file exceeds the maximum upload size” or “Allowed memory size exhausted”, one of these four values is the cause. WordPress even names the file in some upload errors. In the 7.1.3 core file handling code on our test site, one message reads “The uploaded file exceeds the upload_max_filesize directive in php.ini.”

Another core message says a file can arrive empty when post_max_size is smaller than upload_max_filesize. That is the same pair of settings you will change later in this guide. Finding the file comes first. That is the next step.

How to Find the Loaded php.ini File

You can find the loaded php.ini file in three steps. Check the PHP details in Site Health, add a temporary phpinfo page, and read the Loaded Configuration File row. Then delete the page right away, because it exposes details about your server.

Step 1: Check PHP Details in Site Health

Open Tools > Site Health, click the Info tab and expand the Server section. It lists the PHP version, the PHP SAPI and the values for upload size, post size, time limit and memory. Site Health does not print the php.ini path, but it tells you what PHP currently allows.

The PHP SAPI row matters for later. On our test site it said fpm-fcgi. That means PHP runs as FastCGI and a .user.ini file works there.

Step 2: Add a Temporary phpinfo Page

Create a file named phpinfo-check.php in your WordPress folder, using your host’s File Manager or an FTP client. Put this single line inside it. The INFO_GENERAL flag limits the output to the general section, which is the part with the php.ini path:

<?php phpinfo( INFO_GENERAL );

Then open the file in your browser at your own domain, for example example.com/phpinfo-check.php. The PHP manual says phpinfo() prints PHP’s configuration, paths and master and local values of options.

Step 3: Read the Loaded Configuration File Row

Find the row called Loaded Configuration File. Its value is the full path of the php.ini that PHP is using for web requests. The row above it, Configuration File (php.ini) Path, is only the folder where PHP looks.

Check the Server API row too. It shows how PHP runs, for example FPM/FastCGI, and that decides whether a .user.ini file will work.

Warning: Delete phpinfo-check.php as soon as you have the path. The PHP manual notes that full phpinfo output includes environment and request data. A page left online shows those details to anyone who finds it.

If the row says “(none)”, PHP started without any php.ini and runs on built-in defaults. The row about parsed .ini files then lists any extra files from the scan folder.

Find php.ini From the Command Line

You can ask PHP for its loaded file in one command: run php –ini in a terminal. WP-CLI prints the same path with wp cli info. Both show the command-line setup, and the WP-CLI docs say that php.ini file is usually different from the one the web server uses.

On our macOS test machine, php –ini printed this:

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)

The WP-CLI command printed three lines we care about. It showed the PHP binary, the PHP version and the file under “php.ini used”:

wp cli info
PHP binary:	/opt/homebrew/Cellar/php/8.5.5/bin/php
PHP version:	8.5.5
php.ini used:	/opt/homebrew/etc/php/8.5/php.ini

On this machine the command line and the web server happened to load the same file. On a server they often do not, because the PHP manual lets a SAPI-specific file such as php-cli.ini replace php.ini. For web limits, read the phpinfo page.

A one-line command prints the path and the SAPI name together. Run it the same way:

php -r 'echo php_ini_loaded_file(), PHP_EOL, php_sapi_name(), PHP_EOL;'
/opt/homebrew/etc/php/8.5/php.ini
cli

The second line says cli, which proves this is the command-line setup. A web request reports a different SAPI name, such as fpm-fcgi in Site Health, and may load a different file.

Where php.ini Lives on Shared Hosting, a VPS and Local Sites

The php.ini location depends on how PHP was installed. There is no single path for all sites. The PHP manual says PHP searches a list of places in order. The list starts with the SAPI-specific location and ends with the path chosen when PHP was compiled. That is why hosts differ.

• Shared hosting: You usually cannot open the server’s main file. Your host gives you a settings screen such as the MultiPHP INI Editor in cPanel, which edits a php.ini for your domain.
• VPS or dedicated server: You own the server. You can edit the loaded file directly. Run php –ini for the command line and use phpinfo for the web file.
• Managed WordPress hosting: The WordPress docs say some hosts do not let you raise the memory limit yourself. Contact your host to change it.
• Local site on your computer: The same phpinfo page works. Our test machine showed a Homebrew path under /opt/homebrew/etc/php, and your tool may show something else.

The PHP manual also lists a registry lookup and the PHPRC variable, but you rarely need them for WordPress. Use the phpinfo row instead of guessing a path from a blog post.

Can You Edit php.ini on Shared Hosting?

Yes, on most cPanel hosts you can. You do it through the MultiPHP INI Editor and not by opening a server file. The editor changes PHP settings for one domain or for your whole account. Your host can turn that screen off. Ask support if you do not see it.

The cPanel documentation says the interface has a Basic Mode and an Editor Mode. Basic Mode loads the directive values for a domain, and Editor Mode opens a text editor for the php.ini file itself.

1. Open the editor: Log in to cPanel and choose MultiPHP INI Editor in the Software section.
2. Pick the scope: Select Home Directory to change every site you manage, or select one domain name for that site only.
   
3. Change the values and apply them: Edit the directive fields and click Apply. The docs say the system saves the change to php.ini, .user.ini and .htaccess when those files support the directive.

Warning: The cPanel docs call Editor Mode an advanced tool and say mistakes can stop PHP scripts from working. Copy the current contents somewhere safe before you edit.

If your host has no such screen, the next section covers a per-folder file that often works instead.

What Is a .user.ini File and When Does It Work?

A .user.ini file is a per-folder PHP settings file that works when PHP runs as CGI or FastCGI. PHP reads it from the folder of the requested script and each folder up to the document root. It only accepts settings that are allowed per directory. Server-only settings are ignored.

The PHP manual names the exact limits. Only INI_ALL, INI_PERDIR and INI_USER settings are recognized, and PHP rereads the file every 300 seconds by default. On Apache with mod_php, the manual says to use .htaccess files for the same effect.

Upload size is a good fit, because the manual marks upload_max_filesize and post_max_size as INI_PERDIR. We tested it on our site with these steps:

1. Create the file: Add a file named .user.ini to the WordPress root with the two upload lines below.

upload_max_filesize = 64M
post_max_size = 64M

1. Wait for the cache to expire: PHP caches the file. The change can take up to five minutes. On our test site one page showed 64M within a minute while the admin screens needed about five.
   
2. Confirm the new value: Reload Site Health. The Upload max filesize and PHP post max size rows should show the new numbers.
   
3. Check the media screen: Open Media > Add Media File. WordPress prints the maximum upload size under the drop zone.
   

Here is how the four places a PHP setting can live compare:

Not every value takes effect. Our test server sets memory_limit as an admin value in its PHP pool. A memory_limit line in .user.ini was ignored, while max_execution_time = 120 worked.

The PHP manual says an admin value cannot be overridden by .htaccess or ini_set(). A locked value therefore needs a request to your host.

How to Raise the WordPress Upload Limit and Memory Limit Safely

Raise one limit at a time, keep post_max_size larger than upload_max_filesize, and confirm each change on a screen that reports it. The PHP manual says post_max_size must be larger than upload_max_filesize to upload large files. Back up the current file before you edit it.

The core code on our test site shows why both matter. The WordPress max upload size is the smaller of upload_max_filesize and post_max_size. Raising only one of them changes nothing.

For uploads, use these values in php.ini or .user.ini. The PHP manual adds that memory_limit should be larger than post_max_size:

upload_max_filesize = 64M
post_max_size = 80M
max_execution_time = 300

For memory, add a constant to wp-config.php above the line that says to stop editing. The WordPress developer docs say WP_MEMORY_LIMIT sets the most memory PHP can use for WordPress. By default WordPress tries 40MB on a single site:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Note: The same docs warn that a higher memory limit can hide the real problem. If you still run out of memory, deactivate plugins one at a time. Our plugin conflict guide shows how to find the one using the memory.

A slow admin or a blank screen after a limit change is worth a closer look. Our guides on why WordPress is so slow and the WordPress white screen of death cover the usual causes.

Why Do php.ini Changes Not Show Up?

A php.ini change usually stays hidden for one of four reasons: wrong file, old cache, locked value, or a PHP version switch. Each one has a quick check, and the list below covers them. Confirm the loaded path on a phpinfo page before anything else.

• Wrong file: The command line and the web server can load different files. Confirm the path on a phpinfo page.
• Old cache or no restart: The PHP manual says server module versions read php.ini once when the web server starts. For .user.ini, wait out the 300 second cache.
• Locked value: Our test server ignored a memory_limit line in .user.ini. Ask your host to change a locked value.
• PHP version switch: The cPanel docs say a switch to a different major PHP version can stop the system from reading your configuration changes. Save the settings again in the editor.

To test a single value without guessing, add one more line to a temporary page. This prints what PHP uses for that folder right now:

<?php echo ini_get( 'upload_max_filesize' );

Compare that number with the value in Site Health. If they match, PHP has the new setting and WordPress is reading it. Delete the test page afterwards, just like the phpinfo page.

If you manage the server, a restart or reload of the PHP service applies a php.ini edit. If you rely on a host, a WordPress maintenance plan can take this off your plate, and our care plan guide explains what it covers.

Conclusion

So where is the php.ini file in WordPress? It is the PHP configuration file on your server and has nothing to do with WordPress itself. A temporary phpinfo page shows exactly which path is loaded.

Use the phpinfo page for the web path, php –ini for the command line and your host’s settings screen when you cannot open the file. Raise upload and memory limits one at a time and then confirm them in Site Health.

If a limit keeps coming back after you change it, ask your host whether the value is locked.

Frequently Asked Questions (FAQs)