You change one letter on a page, click Update, and the save fails with a 413 error. Other pages save fine. PHP limits look generous, and raising upload_max_filesize did nothing.
That is exactly what a user described in a WordPress.org thread this week: one Elementor page on a dedicated server that refused every save. It happens with the block editor too. The cause is almost never PHP. Something in front of PHP rejects the request because the body is too big.
Why a one-letter edit can be “too large”
Editors do not send the change. They send the whole page. The block editor posts the full post_content to the REST API, and Elementor sends its entire layout JSON through admin-ajax.php. A long landing page with many sections, inline SVGs or pasted base64 images can easily pass 1 MB.
There are three common places that return 413 Request Entity Too Large for a body like that:
- Nginx, through
client_max_body_size, which defaults to only 1m. - ModSecurity, through
SecRequestBodyNoFilesLimit. This limit covers request bodies without file uploads, which is exactly what a page save is. - Apache, through
LimitRequestBody, if someone set it low.
PHP’s post_max_size works differently. When a body exceeds it, PHP throws away the POST data instead of answering with a 413. So a true 413 tells you to look at the web server or the WAF.
Step 1. Find out who sent the 413
Open the browser DevTools (F12), go to the Network tab and click Update again. Click the failed request, which will be /wp-json/wp/v2/pages/ID for the block editor or admin-ajax.php for Elementor. Look at the response headers and body.
A plain HTML page that says “413 Request Entity Too Large” with “nginx” at the bottom points at Nginx. A generic error page, or a 413 from an Apache server, usually means ModSecurity. In the block editor the same failure can also surface as “Updating failed” because the editor expected JSON and got an HTML error page. I covered that message separately in Updating Failed: Not a Valid JSON Response.
Then check the server error log right after a failed save. If you see a line like this, ModSecurity is your culprit:
Request body no files data length is larger than the configured limit (131072)The number in brackets is the current limit in bytes. 131072 bytes is 128 KB, the value in ModSecurity’s recommended config file, so many servers ship with it.
Step 2. Measure how big the page actually is
This tells you which value to set, and it often shows a single bloated page. These queries only read data, so they are safe to run, but take a database backup before you change anything they lead you to.
-- Biggest block editor pages and posts
SELECT ID, post_title, ROUND(LENGTH(post_content) / 1024) AS kb
FROM wp_posts
WHERE post_type IN ('page', 'post') AND post_status = 'publish'
ORDER BY LENGTH(post_content) DESC
LIMIT 10;
-- Biggest Elementor layouts
SELECT post_id, ROUND(LENGTH(meta_value) / 1024) AS kb
FROM wp_postmeta
WHERE meta_key = '_elementor_data'
ORDER BY LENGTH(meta_value) DESC
LIMIT 10;💡 Replace wp_ with your table prefix.
If the failing page sits at the top with a few hundred KB or more, you have found the reason only that page breaks. The request body is a bit larger than these numbers because of the extra fields the editor sends along, so leave headroom.
Step 3. Raise the limit that blocked the request
Back up any config file before you edit it. Change only the layer that sent the 413.
Nginx: client_max_body_size
Find where it is already set, if anywhere:
grep -rn "client_max_body_size" /etc/nginx/No output means you are on the 1m default. The directive works in http, server and location blocks, so you can raise it for one site only:
server {
server_name example.com;
client_max_body_size 64m;
# ... rest of the site config
}sudo nginx -t && sudo systemctl reload nginxnginx -t should report that the syntax is ok and the test is successful. If it does not, the reload is skipped and the old config keeps running, so fix the reported line first. Keep this value in line with PHP’s upload_max_filesize so media uploads do not hit the same wall.
ModSecurity: SecRequestBodyNoFilesLimit
Turning ModSecurity off “fixed” it for the forum poster, but that removes a security layer from the whole server. Raise the limit instead. Find the current value:
sudo grep -rn "SecRequestBodyNoFilesLimit\|SecRequestBodyLimit" /etc/modsecurity /etc/apache2 /etc/httpd /etc/nginx 2>/dev/nullThen set a higher value in that same file, or in your own include that loads after it:
# 2 MB for request bodies without files (page saves, REST, admin-ajax)
SecRequestBodyNoFilesLimit 2097152Per the ModSecurity reference manual, anything over this limit is rejected with a 413. SecRequestBodyLimit is the separate limit that includes file uploads, and the recommended config already sets it to 13107200 bytes (12.5 MB), so you rarely need to touch it for page saves. Pick a value a little above your biggest page from Step 2, not something huge. Restart or reload Apache or Nginx afterwards so ModSecurity picks it up.
Apache: LimitRequestBody
Since Apache 2.4.54 the default is 1 GB (it was unlimited in 2.4.53 and earlier, per the Apache docs), so it only bites when someone lowered it. It is allowed in .htaccess, so check there and in the vhost:
grep -rn "LimitRequestBody" /etc/apache2 /etc/httpd /path/to/wordpress/.htaccess 2>/dev/nullIf a small value turns up, raise it. The value is in bytes, so this is 64 MB:
# .htaccess or <VirtualHost>
LimitRequestBody 67108864For more .htaccess rules that are safe to keep in a WordPress root, see my WordPress .htaccess file examples. If your 413 only appears on media uploads, not page saves, the guide on increasing the upload file size limit covers the PHP side as well.
Doing this in OpenPanel vs cPanel
In OpenPanel, users can edit the vhost file of a domain from Web Server Config > Edit VHosts File, for Nginx, OpenResty, OpenLiteSpeed or Apache, and the panel runs a syntax check with automatic rollback when it saves. Its Web Firewall uses the OWASP Core Rule Set with a per-domain “Monitor only” mode, which is handy to confirm the WAF is the culprit without switching it off. On cPanel, the vhost and ModSecurity settings usually sit with the server admin in WHM, so a regular account holder has to open a ticket.
Keep pages from growing back into the limit
Raising the limit fixes the save, but a 1 MB page is also a slow page to edit and render. Check the biggest pages from Step 2 for pasted images stored as base64, huge inline SVGs and copied sections that could be reusable patterns or Elementor global templates.
💡 After a server move, check these limits again. A new host often brings its own Nginx and ModSecurity defaults, and the page that saved fine yesterday starts failing again.
TL;DR: A 413 on save means the whole page body is bigger than a limit in front of PHP. Use DevTools and the error log to find which layer sent it. Then raise client_max_body_size in Nginx, SecRequestBodyNoFilesLimit in ModSecurity, or LimitRequestBody in Apache, to a little above your largest page. Do not disable the WAF to get there.
