If you need to increase wordpress upload limit to add large images, video, imports, or plugin packages, you should change PHP and server settings carefully so you don’t break other services. This article explains the places that impose limits, provides step-by-step implementation actions, practical examples, trade-offs, troubleshooting tips, safety cautions, and a short conclusion.
How upload limits are applied
Uploads are controlled at several layers: PHP directives (upload_max_filesize, post_max_size, memory_limit, max_execution_time), the web server (Nginx client_max_body_size, Apache LimitRequestBody or php_value overrides), and WordPress itself (the Media upload UI shows the effective maximum). A change at one layer is ignored if another layer still enforces a lower limit.
Key PHP settings and relationships
- upload_max_filesize — maximum size of a single uploaded file.
- post_max_size — maximum total size of POST data; must be larger than upload_max_filesize.
- memory_limit — RAM available to PHP scripts; image processing or large imports can require more memory.
- max_execution_time — seconds a script may run; increase for long uploads or heavy processing.
Safe implementation steps (detailed)
- Backup everything. Take a full site backup (files + database). Use your host snapshot or a backup plugin and store a copy off-site.
- Use staging. Apply changes on a staging site or local copy first to validate behavior and performance under load.
- Check current values. In WordPress Admin go to Media > Add New to see the displayed upload limit. For definitive values create a small phpinfo file on staging or use a Health/Server info plugin to read current PHP directives.
- Choose sensible target values. Example targets for many sites: upload_max_filesize = 128M, post_max_size = 130M, memory_limit = 256M, max_execution_time = 300. Adjust to your needs but keep post_max_size higher than upload_max_filesize.
- Edit PHP configuration where possible.
- If you control php.ini, set the directives there and restart PHP-FPM or Apache: upload_max_filesize = 128M, post_max_size = 130M, etc.
- On systems using per-directory PHP settings, create or edit .user.ini with the same directives and wait for the directive reload window or restart PHP-FPM.
- On Apache with mod_php you can add to .htaccess if your host allows: php_value upload_max_filesize 128M and php_value post_max_size 130M. If you get a server error, remove these lines — many hosts block them.
- Nginx configuration. If using Nginx edit the server or http block and set client_max_body_size 130M; then reload Nginx. If you cannot access Nginx config, request the change from your host support.
- Adjust WordPress memory. In wp-config.php add define(‘WP_MEMORY_LIMIT’, ‘256M’); for front-end operations and consider WP_MAX_MEMORY_LIMIT for admin tasks. Hosts can still cap memory at the PHP level.
- Restart and verify. Restart PHP-FPM/Apache/Nginx as appropriate. Clear any opcode cache. Confirm the new values via phpinfo or the Media uploader and then upload representative files to test processing (thumbnails, EXIF, importers).
Practical examples
- If you need to upload multiple 50 MB videos, set upload_max_filesize = 60M, post_max_size = 120M (for two videos), and max_execution_time = 600 to allow slower connections to complete.
- For single large plugin packages, increasing upload_max_filesize to 64M and post_max_size to 80M is usually sufficient and limits resource consumption.
- For high-volume media libraries consider offloading media to object storage (S3, DigitalOcean Spaces) and serving via a CDN rather than increasing server limits indefinitely.
Trade-offs and considerations
- Increased resource usage. Higher memory and longer execution times raise the risk of resource contention. On shared hosts this can affect other accounts.
- Host policies. Many managed hosts enforce strict upper limits; if your changes don’t take effect the host may be overriding them.
- Security and abuse. Allowing very large uploads can be abused to consume disk or bandwidth; require authentication, limit file types, and scan uploads if possible.
- Performance. Large uploads and server-side processing (e.g., generating large images) can slow the site. Offload heavy processing where feasible.
Troubleshooting common problems
- 413 Request Entity Too Large — a web server limit. For Nginx set client_max_body_size; for Apache check LimitRequestBody or reverse proxy settings.
- WordPress still shows the old limit — PHP changes may not have been applied or opcache could be showing stale settings. Restart PHP and clear caches, then re-check phpinfo.
- Upload appears to succeed but files missing — check wp-content/uploads permissions, PHP error logs, and any SELinux contexts that may block writes. Ensure the PHP process user owns or can write to the upload directory.
- 500 errors or timeouts — increase max_execution_time, check PHP-FPM/Apache error logs, and inspect memory usage. If processing large images fails, ensure GD or Imagick is installed (see PHP image extensions).
- Thumbnail generation fails — confirm PHP has required extensions and that memory_limit is high enough for image processing of the largest expected file.
Rollback checklist and safety cautions
- Keep a list of changed files: php.ini, .user.ini, .htaccess, Nginx server blocks, and wp-config.php.
- If a setting breaks the site, revert the edited file(s) from your backup or snapshot and restart services.
- Limit public upload forms and validate file types and sizes server-side to reduce abuse risk.
- Monitor disk usage and set alerts so uploads cannot fill the filesystem and crash the site.
Conclusion
To increase wordpress upload limit safely, make coordinated changes to PHP and the web server, test first on a staging environment, and back up the site so you can roll back quickly. Monitor resource usage and consider offloading very large or frequent uploads to cloud storage and a CDN. For official guidance consult the WordPress developer resources at developer.wordpress.org and PHP configuration directives at php.net.
