It is incredibly frustrating to be in the middle of updating your content and have the system suddenly halt with a “not a valid JSON response” error. I’ve seen this many times; it usually doesn’t mean your site is broken, but rather that the communication between your browser and the WordPress database has been interrupted by “noise.”
Technically, this happens because the WordPress REST API expects to receive data in a specific format called JSON. If something else—such as a PHP warning, an internal server error, or even a snippet of HTML from a security plugin—gets injected into that stream, the system can no longer read the data and throws this error. Most often, we find the culprit buried in mixed content issues, overly aggressive firewall rules, or a slight desync in your permalink structure.
You can usually resolve this by forcing WordPress to rebuild its internal links (refreshing your permalinks) and auditing your server’s security settings to ensure they aren’t blocking the REST API.
Emergency Stop-Gap: If you need to get your content live immediately and don’t have time for deep troubleshooting right now, install the “Classic Editor” plugin. This bypasses the Gutenberg block editor’s requirement for a clean REST API response, allowing you to save your work while we dig into the underlying server or configuration issues.
Why does the update fail with this specific error?
The reason you are seeing this specific error is that your browser is trying to read a “message” from your server, but that message contains extra noise that it doesn’t know how to process. When you click “Update” or “Publish,” the Gutenberg engine sends an asynchronous request to the WordPress REST API (/wp-json/). Under normal conditions, the server should respond with a clean JSON string confirming that your content was saved successfully. However, if your server injects anything else into that response—such as a PHP notice, a 403 Forbidden page triggered by a firewall, or an automatic redirect caused by an insecure (HTTP) link—the browser can no longer parse the response as valid JSON.
The editor fails because it expects a specific data packet but receives a “broken” string instead. It is important to understand that this isn’t a bug within the WordPress software itself; rather, it is a communication breakdown between your web browser and your server’s environment. Because the Gutenberg block editor relies entirely on this API to function, even a minor server hiccup that disrupts the JSON structure will prevent you from saving your work.
Related guide: How to Fix 413 Request Entity Too Large Error in Nginx
How do I check if my site has mixed content issues?
When your site stops functioning correctly or certain features fail to load, it is often due to a conflict in how the server handles security—a situation known as mixed content. This occurs when your website is loaded over a secure HTTPS connection, but specific components, such as the REST API, attempt to communicate using an unsecure HTTP connection. Because modern browsers prioritize security, they will automatically block these “insecure” requests. If your editor tries to call an endpoint that isn’t wrapped in SSL, the server may refuse the connection entirely or present a warning page instead of delivering the data you need.
To get a clear picture of what is happening, we need to audit your primary settings. Navigate to Settings > General and locate the “Site Address” and “Home URL” fields. You must verify that both of these entries begin with https://. If either one contains http://, the site will struggle to maintain a consistent secure connection.
Additionally, it is vital to ensure that your WordPress configuration recognizes your SSL status correctly. If the system isn’t certain about the security of the environment, it can cause inconsistent behavior during data requests.
If you confirm that mixed content is the issue, we can resolve this by updating your wp-config.php file. By adding a specific instruction to force all administration and system processes through the secure protocol, you can eliminate the conflict:
define( 'FORCE_SSL_ADMIN', true );Related guide: How to Fix cPanel AutoSSL Certificate Renewal Failed Errors
Is my server blocking the REST API request?
When your WordPress editor suddenly refuses to save content or gives you that “not a valid JSON response” error, it usually points to a communication breakdown between your browser and the server. One of the most common culprits in this scenario is a security module called ModSecurity. While these firewalls are necessary to stop hackers, they can be overzealous; they often mistake the long strings of data sent by the Gutenberg editor as “suspicious” activity.
When the firewall triggers, it interrupts the connection and serves a 403 Forbidden or a 500 Internal Server Error page. Because these are HTML pages meant for humans to read, WordPress can’t process them as the JSON data it expects, causing the editor to fail. To confirm if ModSecurity is the roadblock, you need to examine your raw server logs. If you see your specific IP address flagged with a 403 or 500 error during an attempt to save a post, your firewall rules are too aggressive. In this case, you’ll need to reach out to your hosting provider and ask them to whitelist the /wp-json/ path or disable the specific rule that is triggering the block.
Troubleshooting Table
| Audit Pillar | Technical Actions | Business Value |
|---|---|---|
| Permalink Integrity | Resave permalinks in Settings; check .htaccess. | Restores consistent URL routing and API access. |
| SSL Consistency | Verify HTTPS on all internal links and wp-config.php. | Ensures browser trust and prevents “Mixed Content” blocks. |
| Firewall Audit | Check ModSecurity logs for 403/500 errors on /wp-json/. | Prevents the server from blocking legitimate user edits. |
| PHP Environment | Disable display_errors in wp-config.php. | Ensures PHP warnings don’t “pollute” JSON responses. |
Related guide: Fix GoDaddy Managed WordPress Migration Failure
Can a simple permalink refresh fix the problem?
In many cases, the issue is simply that your .htaccess file (on Apache) or your rewrite rules (on Nginx) are not correctly mapping the REST API endpoints. When you navigate over to Settings > Permalinks and click “Save Changes” without actually changing any settings, WordPress flushes and regenerates the rewrite rules.
This process rebuilds the map that tells the server how to handle requests like /wp-json/. If your permalinks were set to “Plain,” the REST API often fails because it cannot find a clean route for the data. You should always use a “Pretty” permalink structure (like Post Name) to ensure the REST API functions correctly.
How do I use the browser’s Network tab to find the real error?
When your WordPress editor throws that “invalid JSON” error, it feels like you’ve hit a dead end because the system is essentially hiding the specific technical failure behind a generic warning. The server actually is sending back a detailed explanation of what went wrong; it just isn’t displaying that information in the standard interface. We can bypass this by looking at the raw data your browser receives.
Follow these steps to see exactly what the server is complaining about:
- Navigate to the specific post or page editor where you are seeing the error.
- Open your browser’s developer tools by pressing
F12(or right-click anywhere on the page and select Inspect). Once that window opens, click on the Network tab at the top. - With the Network tab still open, hit “Update” or “Publish” in your WordPress editor to trigger the error again.
- Look through the list of files appearing in the Network tab. You are looking for a line highlighted in red—this is a failed request. It will often be named
wp-jsonor something similar involving your page ID. - Click on that specific red row and then click on the Response sub-tab (usually located in a sidebar within the developer tools window).
This Response tab will show you exactly what’s happening under the hood:
- 403 Forbidden: This means your server’s security layer (like a firewall or a security plugin) is blocking your specific IP or action.
- 500 Internal Server Error: This indicates a crash in the PHP code, likely caused by a conflict between two plugins or an outdated theme file.
- A wall of text or HTML code: If you see actual words or blocks of HTML instead of the expected
{"code": "success"}data, it means a plugin or your theme is “leaking” information into the background process, which breaks the communication between the editor and the database.
What happens when a PHP warning breaks the JSON format?
It’s incredibly frustrating when you’re trying to update a page or save a setting and the site suddenly stops cooperating, often leaving you with a spinning icon or an “Internal Server Error” message in the admin area. Usually, this isn’t because your database has crashed; it’s because a minor technical hiccup—like a plugin trying to call a function that doesn’t exist—is “polluting” the data stream.
When these small errors occur, they trigger what’s called a PHP Warning. In many default server setups, the system is configured to print these warnings directly onto the screen. While a warning might seem harmless, it ruins the JSON format. Think of JSON as a very strict set of instructions; if even one extra character (like the word “Warning:”) appears before that data, the WordPress editor can no longer read the code and gives up entirely.
To fix this, you need to tell your server to record these errors in a private log file instead of shouting them out on the front end. This keeps the “data stream” clean so the site functions correctly while still letting you see what’s happening behind the scenes.
You can resolve this by editing your wp-config.php file and ensuring the following lines are set correctly:
// Disable public display of errors to prevent breaking JSON responses
@ini_set('display_errors', 0);
define( 'WP_DEBUG', true );
define( '10_DEBUG_LOG', true );By setting display_errors to 0, you are instructing the server to stay quiet on the front end. The errors will still be recorded in a private log for you to check later, but they won’t interfere with the JSON response, allowing your admin tools to function as intended.
How do I fix this if I am on an Nginx server?
If your site is running on an Nginx server—which is common with high-performance hosts like Kinsta or WP Engine—the issue typically boils down to how the server handles long requests or specific URI rewrites. I know it can be incredibly stressful when these technical hurdles pop up, but this is a known configuration issue that we can definitely get sorted out.
Because Nginx doesn’t use .htaccess files like Apache does, you have to address specific configuration blocks. If you have access to your server’s configuration, check that the REST API routes are being handled properly. Another common culprit in these environments is a fastcgi_buffer_size that is set too small; if the buffer isn’t large enough, the JSON response gets cut off mid-stream, which breaks the format and causes the connection to fail. You can resolve this by increasing these values in your Nginx configuration:
fastcgi_buffer_size 128k;
fastcgi_buffers 16 10k;How do I troubleshoot a plugin conflict causing this?
Your site is likely breaking because a specific plugin is “hooking” into the REST API and injecting its own data. If that specific piece of code contains an error or was poorly written, it will corrupt the JSON structure for every page on your site. This is a common headache when a script doesn’t know how to handle the data it’s trying to pass along.
We can isolate the source by following this process of elimination:
- Deactivate every plugin on your site at once.
- Refresh the editor and attempt to save your changes.
- If the save succeeds, reactivate your plugins one by one until you hit the one that breaks the system again.
In my experience, the most frequent culprits are older SEO plugins, security plugins with aggressive “firewall” modes enabled, or page builders that utilize their own custom REST API endpoints. Once you pinpoint exactly which plugin is causing the crash, reach out to that specific developer for a fix or replace it with a modern alternative.
What common mistakes make the problem worse?
A frequent mistake I see is trying to force a fix by hitting the refresh button repeatedly. If you are dealing with a server-side 403 block or a PHP error, refreshing won’t change the result; it simply delays your ability to get into and update your content.
Another common pitfall is attempting to “fix” the JSON by editing the theme’s functions.php file without understanding why the error occurred in the first place. If you find an error in the code and simply delete that line, you might stop the message from appearing on your screen, but you won’t be fixing the underlying logic flaw that caused the issue to begin with.
When should I call a professional?
Sometimes, a technical glitch is buried so deep in the server architecture that it moves beyond the scope of standard troubleshooting. If you find yourself hitting walls with your own fixes, bringing in an expert can resolve the issue much faster than trying to navigate these complexities alone. You should contact a professional developer if:
- You have confirmed through the Network tab that you are receiving a 403 Forbidden or 500 Internal Server Error, but you do not have access to your server’s configuration files.
- The error persists after you have refreshed your permalinks and disabled all plugins.
- Your site is experiencing “Mixed Content” errors on multiple pages that you cannot resolve by simply updating the URL in your settings.
A professional can log into your hosting account, check the mod_security rules directly with the host’s support team, and ensure your Nginx or Apache configurations are optimized for the WordPress REST API. This is often a matter of minutes for an expert who knows exactly where to look in the server logs to pinpoint the failure.