Elementor not loading: five causes our lab reproduced

Why is Elementor not loading?

When Elementor is not loading, the editor page itself has usually arrived. You see the grey Elementor mark and the word LOADING, sometimes with the side panel half drawn, and after a while a box that says “Can’t Edit?” with an Enable Safe Mode button.

What failed is a request the editor makes in the background. We broke a test site five different ways and got the same screen every time. The fix depends on which request failed and why.

Finding that request on a client site, and the plugin or server rule behind it, is the kind of job we take on in WordPress maintenance.

How did we test it?

We ran WordPress 7.1.3 and the free Elementor 4.3.5 on Apache 2.4.67, with PHP 8.4.13 as a separate php-fpm service and pretty permalinks on. The tests ran on 17 Oct 2026, from 4:27 to 5:09 PM ET.

A headless Chrome opened one page in the editor and waited up to 45 seconds for the edit area. With nothing broken, it showed in 1.6 to 2.9 seconds.

Does a firewall or a “disable REST API” setting stop Elementor loading?

Yes, if it blocks the REST API. We added one .htaccess rule that answered 403 Forbidden for anything under /wp-json/elementor/, the way a security rule might.

The editor page itself returned 200. Then it sat on LOADING for 48.9 seconds and showed the Safe Mode box. Sixteen of Elementor’s REST calls, such as variables/list and default-styles, got Apache’s 403 page. The console said “Failed to load resource: the server responded with a status of 403 (Forbidden)” and “AxiosError”.

Blocking all of /wp-json/, as a “disable REST API” setting does, gave the same result in 46.0 seconds.

Blocking only admin-ajax.php did not stop it: the editor loaded in 2.4 seconds, because 4.3.5 loads over REST. Our post on the WordPress 403 Forbidden error shows how to tell which rule sent a 403.

Can a missing .htaccess file keep Elementor on the loading screen?

Yes. We deleted .htaccess and left the permalink setting on /%postname%/.

The editor page still opened, because post.php is a real file. Every /wp-json/ call and the preview frame got Apache’s 404. The editor sat on LOADING for 45.7 seconds. The console added “TypeError: Cannot read properties of null (reading ‘querySelectorAll’) at getDocumentsIdsInCanvas”.

The fix: under Settings, Permalinks we pressed Save Changes without changing anything. WordPress showed “Permalink structure updated.”, wrote .htaccess back, and the editor loaded in 2.0 seconds. The same rewrite rules are behind 404 errors after a permalink change.

Why does Elementor not load when http and https are mixed?

Because a REST request crosses from one to the other and fails its login check. The two addresses live under Settings, General.

With the WordPress Address on http, the Site Address on https and the editor opened over http, Elementor sent its REST calls to https://lab.test/wp-json/. Each one got a 403 with the code rest_cookie_invalid_nonce and the message “Cookie check failed”. The editor sat on LOADING for 45.6 seconds.

Opened over https, the same setup loaded in 1.7 seconds, with a “Mixed Content” warning for two Elementor stylesheets. With both addresses on https it loaded in 1.7 seconds and showed no errors. Our WordPress mixed content guide covers the leftover http links.

Why does Safe Mode not fix Elementor when a plugin prints PHP warnings?

Because the warnings land in REST answers, and in our 17 Oct lab Safe Mode did not reach those.

Our test plugin read a setting that does not exist, so PHP warned on every REST request. With WP_DEBUG and WP_DEBUG_DISPLAY both on, two Elementor routes, kit-elements-defaults and globals, answered 200 with a body that started “<br /> <b>Warning</b>: Undefined array key “color””. The console said “Unexpected token ‘<‘, “<br />\n<b>”… is not valid JSON”. The editor never got past LOADING.

We pressed Enable Safe Mode. The “Safe Mode ON” box appeared and the editor was still on LOADING after 45 seconds, three times out of three. Reading Elementor 4.3.5’s Safe Mode code, we found it filters plugins on the editor, preview and admin-ajax requests but not REST requests.

Two fixes worked. Setting WP_DEBUG_DISPLAY to false in wp-config.php, with WP_DEBUG still on, loaded the editor in 1.6 seconds and sent 22 warning lines to the log. Deactivating the plugin also loaded it in 1.6 seconds. Those settings are listed in WordPress’s debugging guide.

Is turning WP_DEBUG off enough?

Not always. We set WP_DEBUG to false and left PHP’s own display_errors setting on, which is the default in the PHP build we used. The editor still sat on LOADING for 45.6 seconds with the same JSON error.

WordPress does not hide warnings by itself when WP_DEBUG is off, so the display_errors setting in PHP decides. If your host turns it on, set WP_DEBUG to true with WP_DEBUG_DISPLAY false, or ask the host to turn display_errors off. The same stray text breaks the block editor too, as our post on the not a valid JSON response error shows.

Can a low PHP memory limit stop Elementor loading?

Yes, if the host locks it. We set PHP’s memory limit to 24 MB as a locked value, the way some hosts fix it so a site cannot raise it. The editor page returned 200, sat on LOADING for 45 seconds, then showed the Safe Mode box. The PHP error log said “Allowed memory size of 25165824 bytes exhausted (tried to allocate 1568768 bytes)”.

The same 24 MB set as an ordinary value did not break anything. WordPress raised the dashboard to 256 MB by itself, the editor peaked at 28 MB and loaded. A locked 32 MB loaded in 1.8 seconds.

Our page was nearly empty, so 28 MB is a floor. Elementor’s requirements ask for 256 MB and recommend 512 MB. More on the error itself is in our post on WordPress memory exhausted errors.

Does a JavaScript error from an add-on stop the editor?

Not by itself, in our test. A test add-on whose script threw “Cannot read properties of undefined (reading ‘extend’)” left the editor loading in 1.6 and 2.0 seconds.

So look for the failed network request before the red console line.

How do you fix Elementor not loading?

1. Open the browser’s developer tools on the stuck editor, then the Network tab, and type wp-json in the filter. Reload and look for anything that is not 200.
2. A 403 with an HTML page points to a firewall, security plugin or “disable REST API” setting. Turn the rule off, or take /wp-json/ out of it, and test again.
3. A 404 on /wp-json/ while the dashboard works means the rewrite rules are gone. Go to Settings, Permalinks and press Save Changes.
4. A 403 that reads “Cookie check failed” means the WordPress Address and Site Address disagree on http and https. Put both on https.
5. A 200 that starts with “<br />” or “Warning” is PHP printing errors into the answer. Set WP_DEBUG_DISPLAY to false, then find the plugin in the log. Safe Mode did not clear this one in our lab.
6. “Allowed memory size of … bytes exhausted” in the PHP error log means a memory limit the site cannot raise. Ask the host to lift it.

When we take on a stuck editor as a one-off fix, we follow that order on a staging copy: the network tab, then the server and PHP logs, then the plugin or rule that caused it. You get the editor back and a short note on what broke it.

What did we not test?

• Elementor Pro, or a real add-on pack.
• nginx or LiteSpeed, real security plugins, or Cloudflare rules. Our firewall was an .htaccess rule.
• Large pages, or a host’s real memory limits.
• Browser extensions and caching plugins. If you suspect a plugin, our WordPress plugin conflict lab shows how to find the one.

Is your Elementor editor stuck right now?

Tell us the page and paste the first failed wp-json request, or just a screenshot of the console. That is usually enough to say which of these it is.

Not sure the editor is the only problem? Our free site check looks at the whole site, with a written reply within 2 business days. For a single known fault, one-off WordPress fixes lists what we take on.