WordPress Invalid JSON Response: Diagnose and Fix It

You click Update or Publish in the block editor and a red notice comes back: “Updating failed. The response is not a valid JSON response.” Sometimes it says “Publishing failed” instead. Same error. The front end may still work, and the content may have saved despite the notice. Reload the editor and check before you retype anything.

What broke is the reply to the save. The block editor saves through the WordPress REST API (/wp-json/) and expects clean JSON back. This error means something else came back: a 404 page, a firewall block page, a redirect, a PHP notice, or on Elementor 4.3 sites, a chunk of CSS printed in front of the JSON.

Start with the failed request, then work through the least disruptive checks. There’s a separate step if your site runs Elementor 4.3. Don’t start by reinstalling WordPress or restoring a backup. Neither is on this list.

1. First, look at the failed request

This takes a minute and tells you which step to jump to. Guessing takes much longer.

Open the post in the block editor.
Open your browser’s DevTools (F12 or right-click > Inspect) and go to the Network tab.
Type wp-json in the filter box.
Click Update in the editor.
Click the request that turns red, then read its status code and the Response tab.

Here’s how to read what you see:

404: WordPress can’t find its own REST route. Go to step 2.
401 or 403, or an HTML block page from a security plugin or Cloudflare: REST is being blocked. Go to steps 3 and 4.
301 or 302, or the address flips between http and https: site URL problem. Go to step 5.
Response starts with <br /><b>Warning or Notice: a plugin is printing output into the reply. Go to step 6.
Response starts with <style id="elementor-post-: the Elementor 4.3 bug. Go to step 7.
406, 500 or 503 with your host’s branding on the page: server rules. Go to step 8.

It also helps to have the debug log on while you test. Add these two lines to wp-config.php, then check wp-content/debug.log after a failed save:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

If you’ve never turned the log on before, I cover it properly in How To Fix the WordPress White Screen of Death. Turn it off again when you’re done.

2. Re-save permalinks

A 404 on /wp-json/ usually means WordPress’s rewrite rules are stale. This is the cheapest fix on the list.

Go to Settings > Permalinks and click Save Changes without changing anything. That flushes the rewrite rules. If you prefer WP-CLI, run wp rewrite flush.

Still 404? On Apache, check that .htaccess exists in your WordPress folder and that the server is allowed to read it (your host will know it as AllowOverride). On Nginx, the site config needs the usual try_files rule that passes requests to index.php. WordPress’s permalinks docs cover both.

3. Check the REST API itself

Go to Tools > Site Health > Status. If you see “The REST API encountered an error” or “The REST API encountered an unexpected result”, WordPress has confirmed the problem is the API, not your post. Open the details. It usually names the status code it got.

Then open https://yoursite.com/wp-json/ in your browser. You should see a wall of JSON text. If you see an HTML page, a login screen, or a block message, something in front of WordPress is answering instead.

Also check for plugins that “disable the REST API”. Some of them only mean to hide it from logged-out visitors but end up blocking the editor too.

4. Security plugin, firewall or Cloudflare blocking REST

This is a common cause on business sites. Wordfence, other security plugins, a host firewall or a Cloudflare WAF rule decides the save request looks suspicious and blocks it. The editor gets a block page instead of JSON.

Find the block before you change anything. Open your security plugin’s firewall log (Wordfence calls it Live Traffic) and look for a blocked request to /wp-json/ at the time you clicked Update. On Cloudflare, check Security > Events for the same request.

The fix is to allow that one rule or path, not to switch the whole firewall off. On Cloudflare, identify the exact blocked save request and security rule. Exempt that confirmed request from only the rule causing the block, not the entire /wp-json/ path. If you run Rocket Loader or HTML minification, make sure they don’t touch admin or REST responses.

If your wall is the Elementor editor stuck on its loading spinner rather than a block editor save, that’s a different fix order: How To Fix Elementor Not Loading.

5. Site URL or https mismatch

Go to Settings > General. The WordPress Address and Site Address must both match the address your site really uses: https if you have SSL, and the same www or non-www version. If they don’t match, the save request gets redirected and the editor gets HTML, or nothing, back.

This shows up a lot right after an SSL switch or a migration. Fix it in Settings. If those fields are greyed out, look in wp-config.php for WP_HOME and WP_SITEURL, which override the Settings screen. WordPress’s guide to changing the site URL has the safe ways to do it.

6. A plugin or theme printing output into the reply

If the Response tab starts with a PHP warning or notice, a plugin is printing text before the JSON. Minify and optimisation plugins that rewrite responses can do the same thing. It’s a known cause in Gutenberg issue #20365.

The warning or the debug log usually names the file path, and the path tells you which plugin. Deactivate that one first and save again. Only if nothing is named do you go one by one, ideally with the Health Check plugin’s troubleshooting mode so visitors don’t see the change. Switch to a default theme last.

7. Elementor 4.3: Internal Embedding prints CSS in front of the JSON

This has been reported for Elementor 4.3 builds in Elementor’s GitHub issue #37468.

Who gets it: sites on Elementor 4.3.x with CSS Print Method set to Internal Embedding. Reports describe it across several 4.3 releases. In the block editor, saves on Elementor-built pages fail with the JSON error. In the Elementor editor the same bug shows up as a bare “Server Error.” with no number. The change may have saved despite the error, so verify before repeating it.

How to tell: the Response tab starts with <style id="elementor-post- followed by the post ID. Your debug log has a line like this:

headers already sent by (output started at .../elementor/core/files/css/base.php:244)

Why it happens: since the 4.3.0 change, per Wordify’s code trace, Elementor prints a post’s inline CSS straight into the output when its front-end scripts aren’t loaded. That’s exactly the situation during a REST or AJAX save. So the CSS lands in front of the JSON and the editor can’t read the reply. Yoast SEO runs the post content on save for its link indexing, which is why some Yoast sites fail on every Elementor page. Yoast isn’t the cause, just one route into the bug.

The fix:

Go to Elementor > Editor > Settings > Performance. On older menus it’s Elementor > Settings > Performance.
Set CSS Print Method to External File and click Save Changes.
Go to Elementor > Editor > Tools > General and click Clear Files & Data. Older guides call it Regenerate Files & Data.
Purge your page cache and CDN.
Open a page that was failing and save it again.

If the save works but the live page still looks old, that’s a cache problem, and How To Fix Elementor Changes Not Showing covers it.

A few honest limits:

Don’t restore a backup for this. The CSS Print Method setting lives in the database, so it comes back with the restore and so does the error.
External File fixes the common case, not every case. A setting change may not resolve every case. If the response is still malformed, collect the fresh response and logs rather than assuming it is the same bug.
Rolling back to 4.2.4 also stops it, according to reporters and Wordify. If you need that route, follow my rollback order rather than downgrading on live.
Check current Elementor release notes. The status of this issue can change. Test an available update on staging before relying on a workaround indefinitely.

One more thing about “Server Error.” If yours has a number after it, like “Server Error (500)”, that’s a different problem. Go to step 8.

8. Server rules: mod_security, host WAF and limits

If the Response tab shows a 403, 406, 500 or 503 page with your host’s branding, the server blocked the request before WordPress saw it. It often only happens on posts that contain certain words, scripts or iframes, which is a strong hint it’s mod_security or a host firewall rule.

This step comes last because you need your host for it. Send them the time of the failed save, the URL of the request, and the status code. Ask them to check their mod_security or WAF log for that request and make a narrow exception only if the rule is a false positive. Ask them to check the server error log too.

The fix order, as a checklist

Read the failed request in DevTools before changing anything.
Re-save permalinks.
Check Site Health and open /wp-json/.
Look for a firewall or Cloudflare block on /wp-json/ and allow just that.
Match WordPress Address and Site Address to your real URL.
Find the plugin printing output into the reply.
On Elementor 4.3, switch CSS Print Method to External File and clear files.
Ask your host to check mod_security and WAF logs.

If saves still fail after step 8, send me what your Response tab shows and I’ll take a look.

FAQs

Did my post actually save?

Possibly. In some cases the save succeeds and only the reply breaks. Reload the editor and compare the content before redoing any work.

Is “Publishing failed. The response is not a valid JSON response” the same error?

Usually. It is the same class of response error, but inspect the failed request before assuming the cause.

Does switching to the Classic Editor fix it?

No. It hides the error because the Classic Editor doesn’t save through the REST API. The API is still broken, and other things that rely on it, from plugins to the site editor, will keep failing.

Elementor shows “Server Error.” with no number. Is that the same thing?

It can be. Check the network response and logs for the CSS output described in step 7 before treating the two notices as the same issue.