ERROR · 13 · VERIFIED 2026-10allwpcare.com/errors/updating-failed-the-response-is-not-a-valid-json-response/
Errors / updating-failed-the-response-is-not-a-valid-json-response

Updating Failed. The Response Is Not a Valid JSON Response

The block editor got something other than JSON back from the REST API. Open /wp-json/ to see what, then fix permalinks, stray output, or a blocking rule.

The message you see
1−Updating failed. The response is not a valid JSON response.
2−Publishing failed. The response is not a valid JSON response.
Last verified Oct 2026Tested with WordPress 7.1Applies to WordPress 7.1 (tested) · PHP 7.4+
Written and tested by AllWPCare Team · First published Oct 17, 2026

Why it happens

  • The REST API address returns a 404 page instead of JSON. This happens when the web server is not passing pretty-permalink URLs to WordPress, for example a missing or broken .htaccess file.
  • Something prints text before the JSON, such as a PHP notice, a stray space in a file, or a plugin that echoes output. The editor reads the whole reply and cannot parse it.
  • A security plugin, firewall or CDN rule blocks the request and returns an HTML page, often with a 403 status.
  • The WordPress Address or Site Address in Settings → General does not match the address you use, so the editor sends its save request to the wrong place or gets redirected.
  • The request is redirected, for example from http to https, and the reply is a web page.
  • The save request times out or is cut off, so the reply is an error page from the server and not from WordPress.

How to fix it

Try the fixes in this order. Each one is independent: stop as soon as the error is gone.

FIX 01

See what the REST API actually returns

  1. Open https://your-site.example/wp-json/ in a browser tab, using your own address. A healthy site shows a block of JSON that starts with {"name": and your site title.
  2. If you see your theme's 404 page, or a plain "Not Found" page, the REST routes are not reaching WordPress. Go to the permalinks fix.
  3. If you see readable text before the opening {, something is printing output. Go to the stray output fix.
  4. If you see a security or firewall page, or a login page, go to the blocking rule fix.
  5. To check the headers too, run curl -i https://your-site.example/wp-json/ and look for Content-Type: application/json. HTML here means the reply is not JSON.
FIX 02

Re-save permalinks and check .htaccess

  1. Open Settings → Permalinks and click Save Changes without changing anything. This rebuilds the rewrite rules and, on Apache, rewrites the WordPress block in .htaccess.
  2. If WordPress shows "You should update your .htaccess file now", it cannot write the file. Copy the rules it shows into .htaccess in the WordPress root by hand.
  3. With WP-CLI, wp rewrite flush rebuilds the rules. It only writes .htaccess if apache_modules: - mod_rewrite is set in wp-cli.yml, otherwise it prints a warning and leaves the file alone. On nginx, the site config needs try_files $uri $uri/ /index.php?$args;.
  4. Test the fallback address https://your-site.example/?rest_route=/. If that returns JSON while /wp-json/ does not, the cause is rewrite rules or server config, not WordPress itself. I confirmed that split on a test site with .htaccess removed.
  5. Reload the editor and save again.
FIX 03

Find what prints output before the JSON

  1. Look at the text before the opening { in /wp-json/. A PHP notice names the file and line, such as Notice: Undefined variable in .../wp-content/plugins/name/file.php on line 12.
  2. If it names a plugin or theme file, deactivate that plugin or switch themes, then update it or contact its author. See the critical error guide for turning plugins off without the dashboard.
  3. If there is blank space or a hidden character instead, check the start of wp-config.php and of your theme's functions.php. Anything before the first <?php, including a blank line or a byte order mark, is printed on every request. Headers already sent shows how to find it.
  4. Set WP_DEBUG_DISPLAY to false in wp-config.php and keep WP_DEBUG_LOG on. Notices then go to wp-content/debug.log and no longer break the JSON. This only hides notices WordPress controls, not display_errors set in php.ini. It is a stopgap: fix the notice itself. When you are done, turn WP_DEBUG_LOG off and delete debug.log, because anyone who guesses its address can download it.
  5. I confirmed the failure by adding a plugin that printed one line of text in its REST setup. /wp-json/ came back as text/html with the text in front of the JSON, and the editor showed this error.
FIX 04

Check for a blocking rule

  1. Deactivate security, firewall and caching plugins one at a time. Reload the editor and save after each.
  2. If a CDN or host firewall sits in front of the site, look in its log for a blocked request to /wp-json/wp/v2/posts/ or to admin-ajax.php at the time you pressed Save.
  3. A rule that blocks the REST API for logged-out visitors should still allow it for logged-in users. If the rule blocks everything under /wp-json/, the editor cannot save.
  4. Ask your host whether ModSecurity or a similar filter rejected the request. Quote the time and the URL. If Tools → Site Health also reports that the site could not complete a loopback request, the same rule is probably behind both: see your site could not complete a loopback request.
FIX 05

Check the site address settings

  1. Open Settings → General and compare WordPress Address (URL) and Site Address (URL) with the address in your browser bar. Scheme (http or https) and www must match.
  2. With WP-CLI, run wp option get home and wp option get siteurl.
  3. Write down both values first so you can put them back. A wrong siteurl can lock you out of wp-admin.
  4. If either value is wrong, fix it with wp option update home 'https://your-site.example' and wp option update siteurl 'https://your-site.example'.
  5. If a loop or lockout follows, see too many redirects. If the address changed from http to https, also read mixed content for old http:// addresses left in the database.

The block editor saves your post by sending a request to the WordPress REST API and waiting for a JSON reply. This message means a reply came back, but the editor could not read it as JSON. "Updating" appears when you save an existing post or a draft. "Publishing" appears when you publish.

The error is generic. It does not say what came back instead. That is why the first step is to look at the reply yourself.

The top of the block editor with a red notice under the toolbar: Updating failed. The response is not a valid JSON response.
The notice on WordPress 7.1.4 after I pressed Save, with a must-use plugin that prints one line of text when the REST API starts. The post title is a test value.

The three replies that cause it#

  1. An HTML page where JSON should be. A 404 or 403 page, a login page, a redirect target. The REST address is not being served by WordPress.
  2. JSON with extra text in front. WordPress did answer, but something wrote output first. The reply starts with a notice or a space, and a strict parser rejects it.
  3. No usable reply at all. A timeout or a dropped connection. That one usually points at the server or a limit.

I reproduced the first two on WordPress 7.1.3 and got this exact message both times. For the first I removed .htaccess on a site with pretty permalinks. For the second I added a plugin that printed a line of text.

Five stacked steps. The editor presses Save and sends a request to the REST API. A good reply is JSON that starts with an opening brace. Text printed before the JSON breaks it. An HTML page such as a 404, a 403, a login page or a redirect target breaks it too. Open /wp-json/ yourself to see what the editor received.
The editor can only read a reply that is JSON from the first character.

Why /wp-json/ is the right test#

The editor builds the save address from rest_url(), which normally gives https://your-site.example/wp-json/. Opening that address in a browser removes the editor from the picture. Whatever you see there is what the editor received.

What /wp-json/ showsWhat it means
JSON starting with {"name":The API works. Look at the specific save request in the browser's Network tab.
An Apache or nginx "Not Found" pageThe server is not handing the URL to WordPress. Fix permalinks or server rules.
Your theme's "Page not found" pageWordPress is running but has no matching rewrite rule. Re-save permalinks.
Text, then JSONA plugin, theme or file is printing output. Find it from the text.
A login, security or error pageA plugin, firewall or redirect is intercepting the request.

Why Classic editor or Quick Edit still works#

The Classic editor and Quick Edit do not use the REST API for saving. If those work while the block editor fails, that points to the REST route as the problem, not to the post content.

After it is fixed#

Save a post and reload it to confirm that the change stuck. If you changed rewrite rules or the site address, also check the front end and the dashboard. If you changed .htaccess, keep a copy of the working version.

If settings changed along the way and you want to see what, see how to find and undo changed settings. Permalink problems that show up as 404s are covered in posts return 404.

Sources

  1. WordPress: REST API handbook · The routes and the JSON replies the editor depends on
  2. WordPress: REST API key concepts · Routes, endpoints and the ?rest_route= fallback
  3. WordPress core: rest_url() · Builds the address the editor saves to
  4. MDN: Content-Type header · application/json against text/html
  5. MDN: JSON.parse() · Why text before the opening brace makes parsing fail
Newsletter

One email when something breaks or changes.

New plugins and re-tested guides, about twice a month. Never a sales pitch.