You open Media in the dashboard and get a spinning circle that never stops. Or an empty white grid where your images should be. Or the “Add Media” button inside a post opens a window that loads nothing, so you cannot add a featured image or put a picture into a page. The images are still on your website, and visitors see them fine. You just cannot reach them.
When the Media Library will not load, the files are almost never the problem. What has broken is the small background request that fetches the list of images for the screen. Once you know that, the troubleshooting becomes a lot more focused.
How the media grid gets its images
The grid view in Media, and the media window inside the editor, do not load images with the page. They load an empty frame first, then ask the server for the list of attachments through wp-admin/admin-ajax.php. The server is supposed to send back clean data in JSON format, and JavaScript in your browser turns that data into the grid of thumbnails.
Anything that spoils that exchange leaves you with the spinner. A PHP warning printed into the response, a plugin that crashes during the request, a security rule that blocks it, or a JavaScript error in the browser all have the same visible result. That is why the same symptom has so many possible causes.
A quick test that tells you a lot
Go to Media, then Library, and switch to list view using the small icon with horizontal lines near the top left. You can also add ?mode=list to the end of the address, so it reads upload.php?mode=list.
List view is an ordinary page built by the server. It does not rely on that background request. If list view shows your images while grid view spins, you have confirmed that the files and database are fine and the background request is what is failing. If list view is also empty or broken, the cause is deeper, and the server logs become your first stop.
Usual causes, most common first
- A plugin outputting errors or extra text. Even a harmless PHP notice, printed at the wrong moment, corrupts the JSON reply. This often begins right after a plugin update.
- A theme’s functions.php doing the same. Custom code added to a theme, especially code that adds fields or filters to attachments, is a frequent culprit.
- A JavaScript error in the dashboard. A plugin loading broken or outdated scripts on every admin screen can stop the media grid from running at all.
- Optimisation or caching applied to admin pages. Settings that combine or delay JavaScript are meant for the front end. When they leak into wp-admin, the media scripts can load in the wrong order.
- A firewall blocking admin-ajax.php. Security plugins, server firewalls and some CDN rules can block or challenge these requests, particularly if your IP address has changed.
- Not enough memory, or a very large library. Sites with many thousands of attachments and a low PHP memory limit can time out building the list.
- A broken attachment record. Occasionally one attachment has damaged data, and the request falls over every time it reaches that item.
Working through it
Everything in the first group below is look-only. Before you deactivate plugins on a live business site, or edit any file, take a fresh backup you know how to restore.
Look-only checks
- Hard refresh and a private window. Old cached scripts in your browser can cause this after an update. A private window also rules out browser extensions, which do occasionally interfere with admin screens.
- Open the browser console. Press F12 (or right-click and choose Inspect), then open the Console tab and reload the Media page. Red errors that mention a plugin folder name, for example
/wp-content/plugins/some-plugin/, point straight at a suspect. - Look at the background request itself. In the same developer tools, open the Network tab, reload, and click the request to
admin-ajax.php. Under Response, you should see data starting with{"success":true. If you see a PHP warning, an HTML error page, a 403 or a 500 instead, you have found the reason, and the warning will usually name the file responsible. - Check Site Health. Tools, then Site Health, will flag problems such as a failing REST API or loopback request, which often travel together with admin-ajax problems.
Isolate a plugin or theme
The cleanest way on a live site is the free Health Check & Troubleshooting plugin from the WordPress.org team. Its troubleshooting mode disables plugins and switches to a default theme for your login session only, while visitors keep seeing the normal site. Turn plugins back on one at a time and reload Media after each.
If you cannot use that plugin, do the testing on a staging copy rather than switching plugins off in front of customers. When it turns out two plugins only fail together, the approach in our plugin conflict service is the same one we would use here.
Check admin-side optimisation and security settings
In your caching or performance plugin, look for options that minify, combine or delay JavaScript, and make sure they are not applied to logged-in users or admin pages. In your security plugin, check whether your own IP address has been blocked or rate limited. If your site sits behind a CDN with firewall rules, check its event log for blocked requests to admin-ajax.php.
Turn on logging
Add define( 'WP_DEBUG', true );, define( 'WP_DEBUG_LOG', true ); and define( 'WP_DEBUG_DISPLAY', false ); to wp-config.php. Errors are then written to wp-content/debug.log instead of being printed into the response, which on its own sometimes makes the grid load again. That is a clue, not a fix: the error is still there and needs dealing with. Remember to turn debugging off when you are done. Our guide to using WordPress debug mode safely covers the settings in more detail.
Memory and size
If the log shows memory exhaustion or the request takes a very long time, raising PHP memory may help, and so may thinning the library. If your library has grown for years without anyone pruning it, our article on cleaning up the WordPress media library explains how to do that without breaking images on live pages.
If list view is broken as well
When even the plain list view shows errors, a blank area or a partly drawn table, the problem is not confined to the background request. A few things to look at:
- The server error log. Your hosting panel usually has one. Load the Media page, then check the log for entries at that minute. A fatal error names the plugin or theme file that stopped the page.
- Database health. If the log mentions a crashed or missing table, the host can usually repair it. Do not run repair tools on a live store without a backup taken just before.
- One damaged attachment. If the list view stops at the same point every time, sort it by date and narrow down which item breaks it. Removing or re-uploading that single file sometimes brings the whole library back.
- The uploads path setting. After a migration, an old absolute path to the uploads folder can be left behind in settings. Images then fail to resolve even though the files exist. Check that image addresses in list view point to the current domain.
These are less common than a plugin fault, but they explain why a “just disable plugins” approach sometimes changes nothing.
Signs it is something else
If the media library loads but uploads fail, that is a different problem, and our post on image uploads that fail with an HTTP error starts there. If the whole dashboard is crawling and media is just the slowest screen, the cause is probably general admin slowness rather than a media fault.
And if the block editor itself is not loading, or the media window opens but the editor around it is broken, the problem sits with the editor. That has its own guide in our collection of WordPress error fixes.
Keeping the media screen healthy
- After updating any plugin that touches images, attachments or the admin area, open the Media grid once. Catching it the same day makes the cause obvious.
- Do not let front-end optimisation settings apply to the dashboard.
- Keep custom code in a child theme or a small site plugin, with a note of what each snippet does, so it can be switched off quickly when testing.
- Leave
WP_DEBUG_DISPLAYoff on live sites. Errors belong in a log, not in the page.
If the console and the network response mean nothing to you, that is fine; they are developer tools. Send us a screenshot of each, along with what changed recently, and our WordPress bug fix team can usually tell from those alone which plugin or setting to look at first. We back up before touching anything and test the fix on a copy where we can.
Next in this series: WordPress Images Blurry or Cropped? Fixing Image Sizes
