An invalid JSON response usually means the editor expected a structured API reply but received something else, such as an HTML error page, redirect or PHP output. Preserve unsaved content first, then inspect the failed request rather than rebuilding the whole post.
IN THIS ARTICLE
01 Protect the work and identify the request
Copy new text or block content to a secure local file before refreshing. Record whether the error occurs during saving, publishing, media upload or another specific action. The same visible message can have different causes.
Use the browser's network tools, or ask a developer to inspect them, and identify the request that failed at that moment. Capture its endpoint, status and a sanitised response excerpt without exposing cookies, nonces or private content.
02 Example: recognise an HTML response behind an editor JSON error
After preserving unsaved block content, open the failed request in the browser’s Network panel. These example response details show why an editor expecting JSON cannot use an HTML sign-in page, even if that page returned HTTP 200.
Request: POST /wp-json/wp/v2/pages/42
Expected content type: application/json
Observed content type: text/html; charset=UTF-8
Observed body opening: <!doctype html><html>...
Visible page content: Sign in to continueCheck the redirect chain, login session and canonical hostname before changing the page’s blocks. A firewall challenge can produce a similar HTML response, so use the actual body and security evidence to distinguish it from a session expiry. Redact cookies, nonces and private draft text before sharing the capture.
Expected result: The corrected save receives the expected structured response. Reopen the page in a separate editor view and compare its saved content with the preserved copy before discarding your recovery text.
Why does the editor receive HTML instead of valid JSON?
- If the response is a login page, check whether the session expired or the request was redirected to another hostname.
- If it is a firewall or security page, correlate the request time with the relevant security logs.
- If it contains PHP warnings or a fatal error, investigate that component through a protected log rather than displaying debug output publicly.
- If the route returns a not-found page, review the REST URL and rewrite configuration.
- If the response is valid JSON with a WordPress error, use that error code to review permissions or input validation.
03 Apply one targeted correction
Refresh authentication when necessary, correct an inconsistent site URL or investigate a precise false-positive security rule. Do not disable the whole REST API, firewall or HTTPS verification as a generic solution.
If one custom block triggers the problem, reproduce it on a draft or staging copy and review its plugin version. A different editor may avoid the symptom temporarily but does not explain why the expected API response is malformed.
04 Verify the saved data
Retry the specific action once the cause is addressed. Confirm the success message, then open a separate editor or public view and compare the previously unsaved content. A network timeout can leave uncertainty about whether a write succeeded, so inspect before creating duplicates.
Recheck Site Health and fresh logs where relevant, and turn off temporary diagnostics. Keep the preserved local text until the database copy is confirmed.
05 Send an actionable report
Provide the domain, action, endpoint path, response status, time and recent changes. Include a redacted response excerpt that shows whether the server returned HTML, JSON or a PHP error. That evidence makes a precise fix possible without exposing your authenticated browser session or replacing unrelated site content.