WordPress Valid JSON Response Error: Fixes

Short answer

The WordPress "response is not a valid JSON response" message means the editor expected JSON from a REST API request but received another response or could not parse it. Inspect the failed request first, then fix the specific redirect, rewrite, HTTPS, permission, plugin, firewall or server error it reveals.

The WordPress REST API exchanges JSON and is part of the block editor’s publishing workflow.
The message describes the failed response format; it does not identify one universal cause.
Re-saving permalinks can refresh rewrite rules, but it is not the correct fix for every site.
Disabling the block editor hides the affected workflow and should not be treated as the underlying repair.
Capture the response status, URL and body before changing plugins or server configuration.

1. Inspect the failed REST request

Open the browser developer tools, select Network, reproduce the save or publish action and filter for wp-json or ?rest_route=. Record:

request URL and method;
HTTP status;
response content type;
redirect chain;
response body;
console error;
time of the request for matching it to server logs.

An HTML login page, firewall challenge, PHP warning, 404, 403, 500 or redirect loop points to a different repair. This is more reliable than applying a list of unrelated fixes.

2. Check the REST API without overinterpreting the test

Visit https://example.com/wp-json/. A normal public REST index returns JSON. A successful public index does not prove that the authenticated editor endpoint works, but an error, redirect or HTML response is a useful lead.

Also review Tools -> Site Health in WordPress. Site Health can identify REST API, loopback, HTTPS and update problems that affect the publishing environment.

Do not paste code into functions.php to disable REST routes. WordPress documents the REST API as the foundation of the block editor and modern plugin interfaces. If a security rule intentionally restricts REST access, it must still allow the authenticated routes the editor needs.

3. Verify WordPress URLs and HTTPS

In Settings -> General, compare WordPress Address (URL) and Site Address (URL) with the actual installation and public address. Check the exact failed request for:

HTTP-to-HTTPS loops;
www and non-www mismatches;
a wrong subdirectory;
a proxy or CDN returning a different host;
an authentication layer intercepting /wp-json/.

Fix the URL or proxy configuration at its source. Installing an SSL plugin is not a universal requirement and can create another redirect layer if the web server or CDN already handles HTTPS.

4. Refresh rewrite rules without changing the URL structure

If the failed REST route returns 404, open Settings -> Permalinks and click Save Changes. This refreshes WordPress rewrite rules. Keep the existing permalink structure unless a planned migration includes redirects; switching structures casually can change public URLs.

If the 404 remains, inspect the generated Apache .htaccess rules or the equivalent Nginx configuration. Confirm that the web server routes non-file requests to WordPress and that the configuration is writable or managed in the expected place.

5. Test plugins, the theme and the firewall safely

Use a staging copy or a maintenance window. Take a backup, then test one variable at a time:

Temporarily disable security, cache and REST-control plugins first.
Purge application, server and CDN caches.
Test with a default WordPress theme if the response shows theme output or PHP errors.
Review WAF/CDN events for the exact failed endpoint and status.
Re-enable protection and add the narrowest valid rule once the blocker is confirmed.

Do not leave the site unprotected, and do not whitelist all REST traffic when one authenticated route is being blocked.

6. Read the server and WordPress logs

If the response is 500 or contains PHP output, match the request time to the PHP, web server and WordPress debug logs. WordPress’s debugging documentation explains how to write errors to wp-content/debug.log while keeping them out of the browser response.

Unexpected warnings or notices printed before the JSON body can make otherwise valid data impossible for the editor to parse. Fix the plugin, theme or custom code producing that output instead of suppressing the editor message.

Should you disable Gutenberg?

No, not as the repair. The Classic Editor can be a temporary diagnostic or business-continuity option, but successful publishing there does not resolve the failed REST request. A blocked or broken REST API can affect other WordPress and plugin workflows, so the underlying response should still be diagnosed.

Sources

WordPress JSON error FAQ

How do I fix "the response is not a valid JSON response" in WordPress?

Reproduce the error with the browser Network panel open and inspect the failed REST response. Fix the specific status, redirect, HTML error, firewall rule or PHP output shown there. Re-saving permalinks is appropriate when the REST route returns a rewrite-related 404, not as a guaranteed first fix.

What does the error actually mean?

The editor expected a JSON response from a WordPress REST API request and received data it could not parse. The message alone does not prove whether the cause is permalinks, HTTPS, a plugin, a firewall or a server error.

Can a security plugin cause this?

Yes. A plugin or web application firewall can block or challenge a REST endpoint. Confirm it in the failed response or firewall log, then allow only the authenticated route and method WordPress needs rather than disabling protection globally.

Will this error affect rankings?

The editor message is not a direct ranking signal. Its operational impact depends on the cause: failed publishing, broken public URLs or server errors can affect the site, while an admin-only conflict may not affect indexed pages. Check the live output separately.