“The response is not a valid JSON response” in WordPress: what we could trigger

Why does WordPress say “The response is not a valid JSON response”?

The block editor saves through the WordPress REST API and expects JSON back. When the reply is not a valid JSON response, it shows “Updating failed. The response is not a valid JSON response.” On Publish the first word is “Publishing”.

The message comes from WordPress’s own fetch code (api-fetch.js, lines 357 to 358 in 7.1.3, error code invalid_json). It tells you the reply was wrong. It does not tell you what wrote it.

Save errors like this are one of the fixes on our WordPress care and fixes page, where we work on a copy of the site first.

How did we test it?

On 13 Oct 2026 we built a site on WordPress Playground with WordPress 7.1.3, PHP 8.3 and pretty permalinks. A small must-use plugin switched on one fault at a time.

A script logged in, opened a new post in the block editor and pressed save. It recorded the editor’s notice, the save reply’s status and its first 160 characters, and took a screenshot.

Which causes actually triggered the error?

Two of six:

Our plugin printed <p class="lab-promo">Lab plugin: upgrade to Pro</p> in front of the JSON. One stray tag was enough.

Which common fixes did nothing?

We expected whitespace and debug mode to matter. Neither broke a save in our lab.

Blank lines and a byte order mark in front of the reply were read as JSON. They are still worth removing: the blank lines put 20 “headers already sent” warnings in the PHP log in one run.

WP_DEBUG on did not leak the warning either. WordPress 7.1.3 turns display_errors off for REST and JSON requests (wp-includes/load.php, lines 642 to 646; see wp_debug_mode() in the WordPress docs). The warning went to the log, and the post saved.

A PHP fatal is a different problem. WordPress wraps it in JSON, so the editor just says “Updating failed.” The fatal itself is in the log, which we traced in WordPress memory exhausted and the critical error.

Did the post save when WordPress said it failed?

With the plugin fault, yes. Every “failed” save in that case wrote the post. The publish that said “Publishing failed” was published when we opened the Posts list.

So check Posts before you paste your content into a new post. With the firewall fault nothing was saved, because the request was stopped before WordPress saw it.

How do you find the real cause?

Look at what the editor got back. In Chrome or Firefox:

1. Open developer tools and the Network tab.
2. Save the post again.
3. Click the save request, the one to wp/v2/posts followed by the post ID.
4. Read the status and the Response tab.

A 200 with HTML before the opening brace points at a plugin or theme printing output. In our lab the stray HTML carried the class lab-promo, which pointed straight at the plugin. A 403 with a “Forbidden” or “blocked” page points at a security plugin, the host’s firewall or a CDN rule.

How do you fix “The response is not a valid JSON response”?

Remove whatever wrote the bad reply.

For output in front of the JSON, deactivate plugins one at a time on a staging copy and save after each. When we switched our printing plugin off, the next save said “Draft saved.” with a clean JSON reply.

For a 403, find the rule that blocked the save. Check the tool’s log of blocked requests if it has one. Allow requests to /wp-json/ for logged-in editors, or ask the host which rule fired. When our firewall stand-in stopped blocking, the save went through. We have not tried this on a real security plugin or CDN.

This is a fix we do as a one-off job. We read the save reply, find the plugin or rule behind it, and clear it on a copy of the site before the live one.

Site Health (Tools > Site Health) has its own check, “The REST API is available”, listed in the WP_Site_Health developer docs. We did not run it in this lab, so we cannot say whether it catches these faults. Our post on Site Health critical issues covers how to read that screen.

What did we not test?

• Real security plugins, ModSecurity, and Cloudflare or other CDN rules. Our firewall was a stand-in that returned an HTML 403.
• Permalink and .htaccess problems, which need Apache or nginx. Playground has neither.
• An http and https mix, or a Site Address that differs from the WordPress Address.
• Image uploads in the editor and the classic editor.

Is your editor refusing to save right now?

Send us the save reply from the Network tab, or just the message you see, and we will tell you what wrote it.