WordPress "Publishing failed. You are probably offline" Fix

"Publishing failed. You are probably offline." appears in the block editor when you click Publish and the browser's request to the REST API does not complete. The words "probably offline" are a guess: the editor could not get a usable answer, and it assumes your connection dropped. Often the server answered, just not in a way the editor accepts.

A related message is "Publishing failed. The response is not a valid JSON response." That one is about a corrupted or non-JSON reply, and has its own page: Updating failed: not a valid JSON response. Use this page when the failure is a dropped, blocked or unauthorized request.

Start with the Network tab

Open developer tools, switch to Network, click Publish again, and select the failed request (a POST to /wp-json/wp/v2/posts). Then branch:

1. Status (failed) or ERR_*, no HTTP status: a real network problem, a blocked request or a certificate problem. Check your connection, VPN, ad blocker and browser extensions.
2. 401 or 403 with JSON such as rest_cookie_invalid_nonce: your session is stale. Reload and sign in again.
3. 403 with an HTML body: a firewall or security rule blocked the save.
4. 404, 301 or 302: a URL or permalink issue.
5. 500 or 502/504: the server failed; read the PHP error log and see fix 500 internal server error or fix 504 gateway timeout.

Fix 1: session and nonce problems

WordPress REST requests from the editor use your login cookie plus a nonce in the X-WP-Nonce header. If the page was open for many hours, or caching served an old copy of the editor, the nonce no longer matches and the save is refused.

• Copy your content, reload the editor, and try again.
• Log out and log in.
• Clear cookies for the site only.
• Confirm the login cookies are set correctly with the Cookie Checker. If the browser rejects them, see cookies are blocked.

Fix 2: caching and CDN rules

Admin pages and /wp-json/ must not be cached or challenged. If a CDN or caching plugin stores an editor page or REST response, the nonce is wrong for the next person. Identify the layers with the CDN Detector and the HTTP Header Checker: look for cf-cache-status: HIT, x-cache, or age headers on admin URLs. Add bypass rules for /wp-admin/*, /wp-login.php and /wp-json/*. On Cloudflare, a security challenge on REST routes also breaks the editor; see Cloudflare error 1020 if you see Access Denied.

Fix 3: firewall and ModSecurity blocks

Hosts with ModSecurity may block a publish request containing certain strings: script tags in a code block, long inline CSS, a shortened URL or a base64 image. The request shows 403 and an HTML page rather than JSON. Ask your host to inspect the audit log using the time of your attempt, or test by publishing a post with trivial content. If that works, bisect the content to find the trigger. Related: 403 forbidden on wp-admin.

Fix 4: the editor cannot reach the REST API URL

Check the REST root:

curl -I https://example.com/wp-json/

If the result is a redirect to another host or protocol, fix Settings, General so both URLs agree, and clear redirects as described in the WordPress too many redirects fix. A site that serves the dashboard from HTTP while the editor calls HTTPS (or the reverse) creates blocked or cross-origin requests; see WordPress SSL and HTTPS migration.

Fix 5: scheduled and long posts

If the post has a future publish date, WordPress schedules it rather than publishing, and the button says Schedule. If scheduled posts miss their time, the cause is cron, covered in WP-Cron explained and fixed. Very long posts with many embedded images can exceed the PHP post size or time limit; see upload exceeds upload_max_filesize for the related limits.

Fix 6: browser and extension interference

Try a private window with extensions disabled. Ad blockers and privacy tools sometimes block requests whose URLs contain words such as ads, track or analytics, which can be in a post's slug or a plugin's route. Try another browser to isolate it.

Fix 7: plugins and the offline state

Disable plugins that modify the editor, security or REST access, using plugin conflict troubleshooting. If everything works in a different browser on the same network, the issue is local.

How to verify

Publish a test draft and confirm the POST returns 201 (created) or 200. Check the front end loads the new post with the HTTP Status Checker, and watch the PHP log.

Next steps

• Review REST API loopback failed for Site Health warnings.
• Run the Website Health Check.
• Read the HTTP 403 reference.

FAQ

Am I really offline?

Often not. The message is the editor's generic guess when the request fails.

Why does Save Draft work but Publish fail?

Publishing runs additional hooks and can trigger different security rules, plugin code or ping requests. Compare the two requests in the Network tab.

Will my content be saved locally?

The editor keeps unsaved content in memory and may store a local backup, but copy it out before reloading.

Could the REST API be turned off?

Yes. A plugin or snippet can disable it. The block editor needs it for logged-in users.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.