WordPress shows this error when an editor request expects JSON but receives something else.
The replacement might be HTML, plain text, an empty response, or broken JSON.
Inspect the failed request before changing permalinks, plugins, or security settings.
What does not a valid JSON response mean?
The block editor communicates with WordPress through authenticated REST API requests.
The REST API reference says those responses use JSON exclusively.
Parsing fails when another format or malformed output reaches the browser.
Preserve unsaved content first
Keep the failed editor tab open while investigating the response.
Copy the complete post into a protected local document.
Record the title, slug, categories, excerpt, and featured image separately.
Check revisions and autosaves
A previous revision may already contain most recent editorial work.
Open revision history from another tab without closing the failed editor.
Copying content remains safer than trusting an unverified autosave.
Reproduce the exact failing action
Record whether the error follows saving, publishing, uploading, or previewing.
Different actions call different routes and may cross different infrastructure.
Repeat only after preserving the post and opening developer tools.
Capture the failed Network request
Open browser developer tools and select the Network panel.
Preserve the log, repeat one action, and locate the red request.
Record its method, final URL, status, duration, and response type.
Choose the relevant request
Editor pages load many scripts, styles, images, and background requests.
Find the request triggered at the exact failure time.
Post updates commonly target a route containing /wp/v2/posts/.
Read the raw response body
The response body often names the system that replaced WordPress JSON.
A login form, branded firewall page, or PHP warning provides direction.
Save a redacted copy before caches or sessions change it.
Read response headers
Headers reveal content type, redirects, caching, servers, and request identifiers.
A JSON response normally declares an appropriate JSON content type.
Unexpected proxy or firewall headers can identify the responding layer.
Treat the status as supporting evidence
Status codes narrow the investigation but never replace body inspection.
A custom error page can carry an unhelpful status.
Combine status, body, headers, route, and server logs.
Recognise an HTML login page
An expired session may redirect an authenticated request toward login.
The browser then receives HTML instead of the expected JSON object.
Reauthenticate safely, reopen the post, and verify preserved content.
Recognise an HTML 404 page
A branded 404 page suggests routing never reached the intended endpoint.
Confirm the requested path and final path after redirects.
Then compare pretty and non-pretty REST routes.
Follow every redirect
A redirect can change scheme, hostname, path, method, or authentication context.
Developer tools show the complete chain and final response.
Fix the incorrect canonical rule instead of accepting repeated hops.
Check HTTP and HTTPS consistency
Mixed scheme settings can trigger redirects or lose authenticated context.
Confirm the editor, site addresses, REST links, and proxy scheme agree.
Correct trusted proxy configuration when HTTPS terminates upstream.
Check hostname consistency
Switching between root and www hosts can disrupt cookies.
It can also invoke different proxy, cache, or firewall policies.
Use one intended canonical host throughout the request path.
Recognise firewall block pages
Security services often return branded HTML when a rule blocks requests.
The body or headers may include a rule or request identifier.
Use that evidence to request a narrow, reviewed exception.
Recognise PHP output
A PHP warning before JSON makes the complete response invalid.
A fatal error may return HTML or terminate output entirely.
Match its timestamp and message with approved server logs.
Recognise an empty response
An empty response provides no JSON document for the browser.
Timeouts, terminated workers, proxy failures, or connection resets can cause it.
Use timing and infrastructure logs to locate the termination point.
Recognise truncated JSON
A response may begin correctly but end before closing its structure.
Compare received bytes, content length, timing, and proxy records.
Investigate worker termination or intermediary limits rather than editor formatting. We work through it in WordPress memory limits and the block editor.
Recognise prefixed or suffixed output
Whitespace alone rarely explains a modern JSON parser failure.
Visible notices, debug text, or markup surrounding JSON certainly can.
Find the component emitting that text and remove its output.
Test the REST API index
Open the site REST index in a private browser window.
Pretty permalinks normally expose it beneath /wp-json/.
The routes guide documents both supported route forms.
Test the non-pretty REST route
Sites without pretty permalinks use the ?rest_route=/ query form.
Comparing both forms can expose rewrite-specific failure.
Do not mistake a public index test for authenticated update testing.
Use permalink settings as a diagnostic
Broken rewrite rules can stop pretty REST routes reaching WordPress.
The Permalinks documentation says visiting that screen flushes rewrite rules.
Saving unchanged settings is unnecessary solely for that flush.
Do not resave permalinks blindly
A permalink flush only helps when rewrite state caused the failure.
It cannot repair expired authentication, PHP errors, or firewall blocks.
Test routing before and after the controlled action.
Check Apache rewrite handling
Apache sites may depend on permitted rewrite rules within .htaccess.
Compare the file with the host’s supported WordPress configuration.
Back up existing rules before an authorised administrator changes them.
Check Nginx routing
Nginx routing lives in server configuration rather than .htaccess.
Ask the host to trace the failing path through its rules.
Provide both the working index and failing endpoint results.
Verify WordPress and site addresses
WordPress Address identifies the installation location used by core.
Site Address identifies the public location visitors use.
Unexpected differences require deliberate configuration, not casual correction.
Check reverse proxy behaviour
A reverse proxy can redirect, cache, reject, or rewrite REST traffic.
Trace the request identifier across proxy and origin logs.
Confirm forwarded host, scheme, method, path, and authentication headers.
Check CDN caching rules
Authenticated editor traffic should not receive cached public error pages.
Review cache status headers on the exact failing route.
Purge affected objects only after correcting the responsible rule.
Check TLS termination
Managed hosting often terminates encrypted connections before WordPress.
Incorrect forwarded scheme data can produce redirects or insecure URLs.
Use the provider’s documented proxy configuration for WordPress.
Check cookie authentication and nonces
The editor uses WordPress cookies for authenticated same-origin requests. The detail lives in how to fix a blank WordPress block editor.
The authentication guide explains its REST nonce protection.
Expired or stripped credentials can send the request elsewhere.
Confirm the affected account permissions
Permissions decide whether an authenticated user may update that resource.
Test with another temporary account holding the same intended role.
Never grant permanent administrator access merely to bypass the symptom.
Review security plugin logs
A security plugin may reject content patterns, methods, or REST paths.
Use its event log instead of guessing from its settings.
Create the narrowest supported exception after confirming the rule.
Review hosting firewall logs
Hosting firewalls operate outside WordPress and may replace its response.
Give support the timestamp, source address, path, and request identifier.
Ask for the matched rule and safe remediation.
Review request content safely
Some rules react to code samples, markup, or unusual field values.
A clean staging copy can isolate the triggering field.
Redact private content before sharing payloads with outside support.
Compare a blank draft
Create a temporary draft containing one ordinary paragraph.
Use the same user, browser, post type, and publishing action.
Different results distinguish global transport faults from payload-specific rejection.
Compare post metadata
Custom fields and plugin panels can add data to update requests.
A malformed value may trigger output before the normal JSON response.
Test copied content separately from copied metadata on staging.
Use Site Health for context
Site Health exposes configuration and selected communication problems.
Record relevant tests before changing plugins or server configuration.
Its result supports diagnosis but does not replace request evidence.
Isolate plugins on staging
Clone the failing content and account conditions into a staging site.
Change one plugin variable, then repeat the identical request.
Preserve every response because disappearance alone proves little.
Compare a current default theme
Theme code can register fields, hooks, or REST behaviour.
Switch only on staging after preserving the complete reproduction.
Repeat the request with every other variable unchanged.
Enable WordPress logging safely
The WordPress debugging guide recommends testing on staging or locally.
Take a backup before enabling approved diagnostic settings.
Log errors while keeping their public display disabled.
Correlate PHP and server logs
Search logs using the exact failure timestamp and route.
Include PHP workers, web servers, proxies, and firewall services.
One request identifier can connect records across several layers.
Keep errors out of REST output
Public PHP error display can corrupt otherwise valid JSON responses.
Logging preserves evidence without inserting notices into response bodies.
Fix the underlying warning or fatal after locating its source.
Check custom bootstrap code
Must-use plugins and custom loaders run before ordinary plugin controls.
They can emit output or reject requests without appearing obvious.
Inventory them during staging isolation and review recent changes.
Check recent deployments
Align the first failure with plugin, theme, server, or proxy changes.
A timeline narrows suspects without assuming the newest change caused everything.
Reproduce before and after a controlled staging rollback.
Do not disable the REST API
The REST API is the foundation of the block editor.
Disabling it can create more editor failures without fixing malformed output.
Secure authenticated routes through supported permissions and narrow controls.
Do not disable security permanently
A disabled firewall can hide one symptom while exposing the site.
Use a staged comparison and capture the matched rule.
Restore protection after every controlled diagnostic test.
Do not edit stored posts directly
Database edits bypass permissions, revisions, validation, sanitisation, and hooks.
They also avoid the failing route instead of repairing it.
Restore preserved content through supported WordPress workflows.
Separate parsing errors from REST errors
Valid JSON can still describe a normal WordPress REST error.
That response usually contains a code, message, and data object.
The invalid JSON notice instead means parsing failed first.
Avoid public JSON validators
Authenticated responses can contain private content and operational details.
Do not paste them into unknown online validation services.
Use trusted local tooling after removing credentials and personal data.
Recognise maintenance pages
Deployment systems sometimes replace application responses with maintenance HTML.
Compare the failure timestamp with releases and managed hosting events.
Exclude authenticated REST routes from inappropriate maintenance interception.
Recognise gateway error pages
A proxy may return HTML when its upstream becomes unavailable.
Common evidence includes gateway branding and upstream timing headers.
Investigate origin health instead of rewriting valid post content.
Check response compression
Misconfigured compression can corrupt bytes before the browser parses them.
Compare encoding headers and received content across proxy and origin.
Let the infrastructure owner correct duplicated or incompatible compression.
Retest without browser extensions
Privacy and security extensions can alter or block browser requests.
Use a clean browser profile as a controlled comparison.
A clean result identifies local interference, not a WordPress repair.
Prepare a precise support request
Include the timestamp, route, method, status, headers, and redacted response.
Provide one reliable reproduction and one working comparison.
Ask which layer returned that exact body.
Verify the repaired response
Repeat the original action with the same post and account.
Confirm the intended status, JSON content type, and structured body.
Reopen the post and verify that content persisted correctly.
Know the honest weak case
Visiting permalink settings can repair genuinely stale rewrite rules.
It cannot repair every invalid JSON response despite frequent advice.
Prove routing failed before treating a flush as the solution.
Use the valid JSON response checklist
- Keep the failed tab open.
- Copy unsaved post content.
- Record critical metadata.
- Capture the failed Network request.
- Read the raw response body.
- Read its headers and status.
- Follow every redirect.
- Test both REST route forms.
- Check addresses and proxy scheme.
- Review security event logs.
- Correlate PHP and server logs.
- Isolate code on staging.
- Repeat the exact request.
- Verify persisted content.
Frequently asked questions
What causes the not a valid JSON response error?
WordPress expected JSON but received HTML, text, empty output, or malformed JSON.
Should I resave WordPress permalinks?
Only when tests show broken rewrite routing caused the response.
Can HTTPS settings cause invalid JSON?
Yes. Incorrect schemes or proxy settings can create disruptive redirects.
Can a firewall replace the JSON response?
Yes. Firewalls commonly return HTML block pages for rejected requests.
Should I disable the REST API?
No. The block editor depends on REST API communication.
The verdict
Reliable blocks still need reliable transport. Compare the $299 lifetime suite after testing real publishing requests.
Leave a Reply