Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
php.ini is a PHP configuration file, not a WordPress file. Its location depends on your PHP version, operating system, web server and PHP SAPI (such as Apache, CGI or PHP-FPM). The file used by your website can differ from the one used by command-line PHP, so identify the web runtime’s loaded configuration before changing anything.
What php.ini does in a WordPress site
PHP reads php.ini when the PHP process starts. The file controls limits such as upload size, memory available to a request and script timeouts. WordPress runs on PHP, but it does not keep a standard php.ini inside wp-admin, wp-content or wp-includes.
There is no universal “WordPress php.ini path.” A server can have separate configuration files for different PHP versions, virtual hosts or SAPIs. A command such as php --ini reports the CLI configuration, which may not be the configuration serving your web requests.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to find the php.ini file WordPress is actually using
Use a web-runtime PHP information check
- Create a temporary file outside public view if possible, or protect it with authentication. Give it a distinctive name such as
php-check.php. - Put this minimal code in the file:
<?php phpinfo(); - Open the file through the same domain and PHP handler that serves WordPress.
- Search the output for Loaded Configuration File. That value is the active
php.inipath for the web request. Also note Server API, the PHP version and any additional parsed configuration files. - Delete the file immediately after checking it. A publicly accessible
phpinfo()page exposes useful details to attackers.
Check from the server when you control it
For command-line PHP, run:
php --iniThat output is useful for CLI jobs, WP-CLI and cron tasks, but it does not prove that WordPress’s web requests use the same file. On a self-managed server, compare the CLI result with the web result and identify the PHP-FPM pool or web-server handler serving the site.
#1 Best Overall
Use WordPress diagnostics carefully
Tools such as WordPress Site Health can show PHP version and selected limits. They may not expose every path, so a short-lived, access-protected PHP information check is the more direct way to identify the loaded file.
Editing php.ini on a self-managed server
- Record the active PHP version, Server API and loaded configuration path.
- Back up the existing file before editing it.
- Open the loaded file with administrative privileges and change only the directives you need. Use valid INI syntax, for example
upload_max_filesize = 100M. - Check the complete set of related limits rather than changing one value in isolation.
- Reload or restart the service that owns the PHP process. Depending on the stack, that is usually the relevant PHP-FPM service or web-server service. A file edit does not affect already-running workers until they reload.
- Verify the effective values through the web runtime, not only with a CLI command.
Paths vary by distribution and installation. Versioned Apache and PHP-FPM directories are common, but treating any one example path as universal can lead you to edit the wrong runtime.
Rank #2
Which PHP settings control WordPress upload errors?
These directives interact:
| Directive | What it limits | Illustrative value |
|---|---|---|
upload_max_filesize |
Maximum size of one uploaded file | 100M |
post_max_size |
Total size of a POST request, including uploaded files | 120M |
memory_limit |
Memory available to a PHP request | 256M |
max_execution_time |
Maximum execution time for a script | 300 seconds |
max_input_time |
Time allowed to parse request input | 300 seconds |
The values shown are an illustrative pattern, not a universal recommendation. PHP and WordPress require post_max_size to be larger than upload_max_filesize; WordPress also advises that memory_limit be larger than post_max_size. Leave headroom for multipart request overhead and other application data.
PHP’s documented core defaults include memory_limit of 128M and upload_max_filesize of 2M, but hosting images and PHP releases can differ. Always inspect the active runtime instead of assuming those defaults.
What to do when you cannot edit the global php.ini
Use your host’s PHP settings panel
Shared and managed hosts commonly expose per-site PHP controls in a hosting panel. This is generally the safest option because the provider knows which handler and pool serve your site. If no controls are visible, ask support which directives can be changed and what limits are enforced at server level.
Ask the host to make the change
A provider may allow a higher limit only after a support request, or may refuse changes on shared infrastructure. Include the domain, PHP version, desired directive values and the exact WordPress error.
Rank #4
Try a per-directory .user.ini
Where the host and PHP SAPI permit it, a .user.ini file in the site’s directory can provide per-directory PHP overrides. Support, scan interval and allowed directives vary, so confirm the mechanism with the host. Changes may not appear immediately because PHP can cache these files for a period.
Recommended Free Tools
Use Apache .htaccess only when supported
On an Apache configuration that permits PHP overrides, WordPress documents php_value entries for settings such as memory and upload limits. PHP-FPM and many CGI setups reject those directives; the result can be a 500 error. If that happens, remove the lines promptly and use the control panel or host-supported method instead.
Why editing wp-config.php may not change the PHP limit
WordPress provides two memory-request constants, which must be added before WordPress loads wp-settings.php:
define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );These constants ask WordPress to request memory for frontend and administration work; they do not rewrite a host-enforced PHP policy. If PHP’s memory_limit is lower, or runtime changes are disabled, the effective value will remain lower.
WordPress documents default requests of 40 MB for a single-site frontend and 64 MB for a Multisite frontend, with 256 MB for administration requests. A 2026 WordPress Hosting Team guideline lists 128M as a minimum, 256M as a recommended default and 512M or more for resource-intensive sites; actual needs depend on plugins, themes, traffic and workload.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →How to verify that a change worked
- Check the value through the website’s PHP execution context, using Site Health or a protected diagnostic page.
- Confirm both the loaded configuration file and any additional parsed INI files.
- Repeat the check after reloading PHP-FPM or the web server.
- Test the original operation, such as uploading a file just below the configured limit.
- If the value is unchanged, ask the host which PHP handler, pool and per-directory override mechanism applies.
Keep diagnostic files private and remove them as soon as verification is complete.
Choosing the right editing method
| Method | Scope | Compatibility and permissions | Main risk |
|---|---|---|---|
Global php.ini |
Server or runtime-wide | Requires server access; suitable for an operator who controls the PHP installation | Affects other sites and requires a service reload |
| Hosting control panel | Usually per-site | Best fit for managed or shared hosting when provided | Provider caps may still apply |
| Host support ticket | Per-site or pool-level, according to provider policy | No shell access required | The requested value may be refused |
.user.ini |
Directory or site scope | Only where the SAPI and host enable it | Unsupported directives or delayed scanning |
Apache .htaccess |
Directory scope | Apache configurations that allow PHP overrides | Can trigger a 500 error under PHP-FPM or CGI |
wp-config.php constants |
WordPress memory requests | WordPress-level change; no global PHP access needed | Cannot override a server-enforced PHP limit |
Practical troubleshooting checklist
- Wrong file edited: compare the web Loaded Configuration File with the path you changed.
- CLI and website disagree: they are using different SAPIs or PHP versions; verify both separately.
- Change appears ignored: reload PHP-FPM/web workers and check additional INI files and host-level policies.
- Upload still fails: ensure
post_max_sizeexceedsupload_max_filesize, and allow enough execution and input time. - Site returns HTTP 500 after an
.htaccessedit: remove thephp_valuelines and use the provider’s supported method. - Host will not raise the limit: use the host’s documented ceiling, reduce file size, or move to infrastructure with PHP configuration controls.
The Bottom Line
Find the configuration loaded by the web SAPI first. Edit global php.ini only when you control the server; otherwise use the host’s PHP panel, a supported .user.ini or an approved support request. Keep post_max_size above upload_max_filesize, verify the effective web values after reloading services, and remember that wp-config.php can request WordPress memory but cannot defeat host-enforced PHP limits.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
