How to Fix Elementor Not Loading or Not Working?

When Elementor shows a loading spinner that never finishes, a blank canvas, or a gray widget panel, the published page may still remain available.

What the screen shows is an editor initialization failure, not proof that the page itself is damaged. The public page is serving content that was already saved, while the editor must also load its scripts, WordPress data, preview iframe, and a fresh server response.

Reloading the public page therefore does not test the same work. A browser extension can block only the editing screen, one damaged widget can affect only one page, and a server can keep serving cached pages while rejecting the larger requests Elementor needs in WordPress.

Before changing the live site, compare the result with the table below. That single comparison prevents most unnecessary plugin, theme, and server changes.

1. Find Out Whether the Failure Follows the Browser, One Page, or Every Page

The fastest useful test is not an update or reinstall. It is opening the same editor in a clean browser session, then opening a different Elementor page. The result shows how much of the site is actually affected.

1. Open the affected page in a private or incognito window using a current desktop browser. Elementor’s editor is not supported as a mobile or tablet editing environment.
2. If it opens there, return to the normal browser and disable ad blockers, script blockers, privacy extensions, or antivirus browser add-ons for the site. Re-enable them one at a time after the editor works.
3. Open a second Elementor page. Then create an unpublished blank draft and select Edit with Elementor.
4. In WordPress, open Elementor > Editor > System. Some older Elementor builds show this as Elementor > System Info.
5. Check the installed WordPress, PHP, Elementor, and Elementor Pro versions against Elementor’s current system requirements. Keep the free and Pro plugins on compatible releases.

   

If only the normal browser fails, leave WordPress unchanged and correct the browser extension or site data. If only one page fails, use Method 3. When every page fails in more than one browser, Safe Mode provides the next clean comparison.

If an update is needed, back up the site and test it on staging first. Update the free Elementor plugin before Elementor Pro so the two do not remain on mismatched versions.

2. Use Safe Mode to Prove a Plugin or Theme Conflict

Elementor Safe Mode opens the editor without the active theme and ordinary third-party plugin code for the logged-in administrator. It does not alter the version visitors see, so it is safer than deactivating the live site’s plugins as the first experiment.

This test is not needed when the editor already opens and only the published page looks wrong. Safe Mode also cannot diagnose a widget panel that is loading its own third-party scripts.

1. Open Elementor > Tools, set Safe Mode to Enable, and save the change. You can also accept Elementor’s Safe Mode prompt when it appears on the failed editor.

   

2. Reload the same page. If only the widget panel remains stuck, note that result: Elementor says Safe Mode does not remove third-party scripts loaded inside that panel, so a failed panel is not a conclusive Safe Mode test.
3. If the full editor opens, use a staging site or a maintenance window to deactivate every plugin except Elementor and Elementor Pro.

   

4. Test the editor, then reactivate the other plugins one at a time. Pay particular attention to Elementor add-ons, caching/minification tools, security plugins, and anything updated immediately before the problem began.
5. If no plugin reproduces the failure, test with Hello Elementor. Disable any page preloader or custom script supplied by the normal theme before replacing the theme permanently.

Elementor’s Safe Mode documentation confirms that visitors continue to receive the normal theme and plugins during this test.

If the editor fails again when one plugin or the normal theme returns, leave that item disabled only long enough to update it, correct its settings, or ask its developer for a compatibility fix. Check what the site loses before leaving a required plugin disabled.

A failure that began immediately after an Elementor release may require a known-good backup or Elementor’s Version Control rollback. Back up first, and keep Elementor and Elementor Pro on compatible versions.

3. Check Memory and the Server Response When Every Page Fails

When Elementor fails across pages and browsers, the editor may be exhausting WordPress memory or receiving an incomplete PHP response. The published site can still look normal because cached front-end pages use fewer resources than the editor.

Elementor currently lists 256 MB as the WordPress memory minimum for Elementor and Elementor Pro, with 512 MB recommended. WooCommerce and other large plugins may require more.

Do not use this server method when only one page fails or when the editor already works in another browser. Those results point elsewhere.

1. Open Elementor > Editor > System and note the WordPress Memory Limit, PHP version, PHP memory limit, and any warnings.
2. Reproduce the failure once and note the time. Ask the host to inspect the PHP error log, web-server log, and firewall log for that request.
3. If WordPress memory is below Elementor’s requirement, ask the host to raise both the WordPress and server-side PHP limits. Adding a WP_MEMORY_LIMIT value cannot exceed the ceiling enforced by the host.
4. Ask the host to correct any memory exhaustion, fatal PHP error, execution timeout, failed write permission, ModSecurity block, or broken compression response it finds.
5. Reload the same editor after the server change.

   

A visible 500 Internal Server Error belongs to this server-side check. Our Elementor 500 error guide covers the additional save and update failures associated with that code.

If correcting the logged PHP, memory, or firewall error restores the editor, keep the confirmed server value and remove any temporary debugging. If the host finds no failed request at the recorded time, continue to Method 5 and test Elementor’s alternate loader.

4. Change Elementor’s Loader and Clear Only the Stale Editor Data

Elementor includes an alternate loader for servers that fail while decoding or returning the editor’s long JSON response. This is especially relevant when the browser console shows ERR_CONTENT_DECODING_FAILED or ERR_EMPTY_RESPONSE.

This setting is not needed when the console already names a plugin conflict, URL mismatch, or blocked frame. Correct that specific error instead.

1. Open Elementor > Settings > Advanced.
2. Set Switch Editor Loader Method to Enable, save the setting, and test the editor.

   

3. Open Elementor > Editor > Tools > General and select Clear Files & Data. Older Elementor versions label the same maintenance action Regenerate Files & Data.

   

4. Purge the WordPress cache, host cache, and CDN cache. Then clear the saved data for this site in the browser rather than deleting every browser session. Our single-site cache guide shows that narrower cleanup.
5. Close the old editor tab and open a fresh one.

Elementor says the alternate loader is safe to leave enabled. If it fixes the editor, the host should still inspect response compression and resource limits so the reason for the original loader failure is understood.

For rollback, set Switch Editor Loader Method back to Disable. Keep normal caching enabled afterward and exclude only WordPress admin/editor URLs that were serving stale data.

If the editor loads after clearing the generated files, the cached copy was stale. If it still fails, continue to Method 6 only after a migration or HTTPS change; otherwise continue to Method 7 for the console check.

5. Correct Stored URLs After a Migration, Domain Change, or HTTPS Switch

Elementor loads its preview in a frame. After a migration, the WordPress dashboard can use one domain or protocol while Elementor’s saved data still requests another, leaving the editor blank or filling the console with mixed-content and cross-origin errors.

Do not run a search-and-replace on a site that has not moved, and back up the database before replacing any URL.

1. Open Settings > General. Confirm that WordPress Address (URL) and Site Address (URL) use the intended domain and the same https:// protocol.

   

2. Open Elementor > Editor > Tools > Replace URL. Enter the exact old URL and new URL, review both values, then run the replacement.
3. Return to Tools > General and select Clear Files & Data.
4. Open Settings > Permalinks and select Save Changes without changing the structure.

   

5. Clear the site and CDN caches, then reopen the editor. Reconnect the Elementor license if the domain itself changed.

Elementor’s official URL-change instructions use this replacement and file-clearing sequence.

If the WordPress address fields are locked, ask the host or site administrator whether WP_HOME and WP_SITEURL are defined elsewhere before editing them.

6. Use the Browser Console to Identify Cloudflare, Iframe, or Firewall Blocking

A gray preview with red console errors is more useful than another reinstall. The console is useful because Elementor’s scripts and preview frame are browser requests. The failed request identifies whether the browser, Cloudflare, firewall, or server rejected it.

Do not use this method to change frame headers or firewall rules when the console shows no matching error. Those are security controls, not general performance settings.

1. Right-click the blank editor, select Inspect, open Console, and reload the page.
2. Match the red error to the action below.

If the editor loads after one targeted rule or header correction, keep the narrower exception and restore any security feature disabled for testing.

Download Elementor’s System Information and save the console message. Ask the host for the matching PHP and firewall logs.

If the editor still fails, include whether it works in a private window, on another page, and in Safe Mode when contacting Elementor. Those results identify the failed request far more clearly than a list of updates and reinstalls.