Skip to content
Rescue 404
Rescue

WordPress Admin Problems

WordPress Media Library Not Loading (WordPress Repair)

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

A blank WordPress Media Library or an endless loading spinner usually means its AJAX or REST request is failing, often because of a plugin conflict, JavaScript error, blocked admin request, exhausted PHP resources, or bad upload permissions. Test List view and a private window, inspect the failed request, then isolate plugins and permissions instead of deleting media records.

The files may still exist even when the Media Library grid cannot display them. Grid view depends on browser JavaScript and background requests, while List view uses a more traditional admin page, so comparing the two quickly separates a display/request failure from missing attachments. This guide restores the interface while protecting the uploads folder and attachment database records.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

What the error means

The Media Library is not a direct view of files on disk. WordPress stores each uploaded item as an attachment record in the database and links it to a file under `wp-content/uploads`; the grid then requests batches of those records asynchronously and renders them with JavaScript. If that request returns a 403, 500, invalid JSON, login page, or PHP warning, the grid can stay blank or spin forever even though the images still load on public pages. List view may continue working because it follows a different rendering path. The repair is to identify which layer failed—browser script, WordPress extension, authentication, server security, database query, or filesystem—not to re-upload everything.

Common symptoms

  • Media → Library grid is blank or shows a spinner that never finishes
  • List view displays attachments while Grid view does not
  • The media modal inside the block editor or page builder opens empty
  • Browser console reports a JavaScript error when the library opens
  • Network tools show a failed `admin-ajax.php` or REST API request with 403, 500, or invalid JSON
  • Existing images still appear on public pages even though the admin library is empty
  • Filters, search, or “Load more” fail while the initial library page partially renders

Most likely causes

  1. 01 A plugin or theme adds broken JavaScript to WordPress admin or alters media queries
  2. 02 Security plugin, host WAF, or CDN blocks `admin-ajax.php` or a REST media endpoint
  3. 03 PHP fatal error, memory exhaustion, or timeout occurs while querying attachment metadata
  4. 04 Incorrect permissions or ownership prevent WordPress from reading the uploads directory
  5. 05 Expired authentication cookie causes background requests to receive a login page instead of JSON
  6. 06 Optimization or minification incorrectly combines scripts in the admin area
  7. 07 A malformed attachment record or enormous media table query stalls a specific page of results

What changed before the problem started

  • Plugin, theme, WordPress core, or PHP version was updated
  • Security rules, CDN settings, or host WAF protection changed
  • A media offload, optimization, gallery, or page-builder plugin was installed
  • The site was migrated and file ownership, URLs, or uploads paths changed
  • A large media import or thumbnail regeneration ran shortly before the library stopped loading

Troubleshooting steps

  1. 01

    Compare Grid view, List view, and a private browser session

    Open Media → Library, switch to List view, then test both views in a private window. If List works but Grid does not, attachments are present and the likely fault is JavaScript or an asynchronous request. Record the exact view that fails.

  2. 02

    Check the browser console and failed network request

    Open developer tools before reloading the library. Note the first red console error and inspect requests to `admin-ajax.php` or `/wp-json/` for status code and response text. A 403 points toward security; a 500 points toward PHP; HTML from wp-login points toward cookies or session expiry.

  3. 03

    Clear admin caches without deleting media

    Clear browser cache and site cookies, sign in again, and purge any CDN or optimization cache. Disable JavaScript combination or delay features for wp-admin. Do not clear database tables or remove files from `uploads` as a cache-fixing shortcut.

  4. 04

    Deactivate the most likely plugin and retest

    Start with the plugin updated most recently, especially media offload, image optimization, gallery, security, caching, or page-builder plugins. Retest after each change. If there is no clear suspect, deactivate plugins in controlled batches on staging until the library returns.

  5. 05

    Check WordPress and PHP logs at the failure time

    Enable `WP_DEBUG_LOG` briefly with `WP_DEBUG_DISPLAY` off, reload Media Library once, and inspect `wp-content/debug.log` plus the host PHP log. Match the timestamp to a fatal, memory error, or database warning, then disable debug logging when finished.

  6. 06

    Verify uploads remain readable and writable

    Confirm `wp-content/uploads` exists, current-year/month directories can be read by the web server, and the hosting account has free disk space. Use the host’s recommended ownership and permissions; do not solve this by making the directory world-writable.

When to stop troubleshooting

Stop if the uploads directory appears deleted, a database repair would affect thousands of attachment records, server logs show repeated corruption or malware, or production editors cannot safely pause work. Also escalate when you lack access to PHP/WAF logs or a busy media library needs a staged rollback; deleting attachments while the interface is blank can turn a display problem into permanent data loss.

Information to collect before requesting help

  • 01 Whether Grid view, List view, editor media modal, or all three fail
  • 02 Screenshot of the blank library or permanent spinner
  • 03 First browser console error and failed request URL, status, and response
  • 04 WordPress, PHP, active theme, and recently changed plugin versions
  • 05 PHP/debug log entries at the exact reload time
  • 06 Whether existing images still load on public pages
  • 07 Uploads directory ownership, permissions, free disk space, and migration history
  • 08 Approximate attachment count and whether the failure starts on a certain page or filter

How a professional repairs the problem

A pro first proves whether attachment records and files still exist, then captures the exact failed grid, AJAX, or REST response. We isolate extension code, correlate server and browser logs, correct authentication or WAF handling, repair safe ownership and permissions, and profile attachment queries when scale is involved. Only after the library request is healthy do we repair metadata or regenerate thumbnails, with backups and batch limits.

Frequently asked questions

Are my images gone if the Media Library is blank? +
Usually not. If images still load on public pages or appear in List view, the files and attachment records exist; the grid request or rendering layer is failing.
Why does List view work when Grid view spins forever? +
Grid view relies more heavily on JavaScript and asynchronous requests. List view uses a conventional admin page, so it can survive a broken script or blocked media request.
Should I regenerate thumbnails first? +
No. Thumbnail regeneration fixes missing image sizes, not a request that cannot load attachment records. Diagnose the failed network response before starting a resource-heavy rebuild.
Can a security plugin break only the Media Library? +
Yes. A rule can block a specific AJAX action, REST route, file type, or request payload while the rest of wp-admin continues to work.
Will deactivating a media plugin delete its files? +
Normal deactivation should not delete uploads, but offload plugins may control remote delivery. Back up first, read the plugin’s behavior, and test on staging when storage is external.
Is this the same as an HTTP error while uploading? +
No. An upload HTTP error happens while processing a new file. A library loading failure happens while querying or displaying existing attachments, though both can share resource or security causes.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.