If the WordPress Media Library is not loading, do not start by uploading your pictures again. An empty grid can be a display or filtering problem, even when attachment records and some public files still exist. First compare what WordPress lists with what the browser can actually open.
This guide is for a business owner facing a blank library, an endless spinner or missing thumbnails while choosing an existing image. A new upload that reports an HTTP error is a different starting point. Use the image upload error guide for that case, especially when a failed attempt may already have saved a file.
Check the filters before treating images as missing
Open Media > Library in your own WordPress dashboard. Record any search text, media type, date or plugin folder currently selected. Then compare with an empty search, All media items and All dates. Do not use Bulk Select or Delete during this check.
The official Media Library reference describes its filters and two views. A library filtered to one month, PDFs or Unattached will not show the same collection as the full library. Folder and role-management plugins can add their own restrictions.
If the missing picture returns after changing a filter, check that it is the intended file before selecting it. That resolves a visibility question, not a broken upload. Also remember that Unattached does not mean unused; it is not a safe deletion list.
Compare grid view with list view
Use the grid and list icons above the library. Keep the same search and filters in both views. List view presents rows of attachments; grid view presents tiles. Search for one known public image, such as the current blog cover, rather than trying to prove the whole library is healthy at once.
| What you find | What it establishes | Next safe step |
|---|---|---|
| The item appears after clearing a filter | The previous view excluded that result | Check the selected file and keep the library intact |
| List view shows the item but grid view keeps spinning | At least that attachment record can be listed | Check its file URL, then investigate the grid’s loading request |
| Tiles appear but their pictures are broken | The library can draw results, but an image request may fail | Compare the attachment’s original URL with the failing thumbnail URL |
| Neither view finds a known item with matching filters | The record is not visible in these checks | Check account restrictions and recent migration or restore history before re-uploading |
A working list view does not prove that every image file is intact. WordPress can retain a database record after a file or generated size becomes unavailable. Conversely, a file may exist on the server without a usable attachment record. Keep those questions separate.
For the known public image, open its attachment details and inspect the file URL without editing anything. Attachment details can save changes automatically, so avoid typing into the title, caption or alt fields during diagnosis. Open the existing file URL in another tab, then inspect a public page that uses it. Do not expose private customer media for this test.
If only the grid fails, inspect how it loads
The standard WordPress media grid obtains attachment data through a background request. The core attachment-query handler checks access, applies query filters and prepares data for the browser. This is different from the image file request used to paint each thumbnail. Plugins and page builders can add other requests.
You do not need to change code to make the first comparison. In your browser’s developer tools, open Network, reload the affected library and look for a request to admin-ajax.php whose request data includes query-attachments. A developer can help identify it. Record the time, response status and whether the reply looks like data, a login screen, an error or a security challenge.
A successful HTTP status alone does not establish a successful library response. A login page or error output can arrive with status 200. Equally, a failed request is not proof that a particular plugin caused it. Compare the exact request with server or security logs before changing rules.
If the Console shows an error, retain its wording and relevant component name. A script path is a lead for investigation, not a verdict. Do not paste a complete network export into a public forum: it can contain cookies, request tokens and private media URLs.
Try one controlled browser comparison
Use another current browser or a clean profile and sign in through the site’s normal login. Open the same library, filters and known image. If that works, compare the original browser’s extensions and stored site data before changing WordPress for every visitor.
Do not clear everything before preserving an unsaved editor draft. Sign out and back in only when your work is saved, and never disable a security warning to make a test pass. If the other browser also fails, collect the matching evidence rather than repeating uploads.
A failure limited to a page builder’s image chooser also needs its own comparison: does Media > Library work outside that editor? If it does, the editor’s integration or loading context deserves attention. That does not establish which component is defective.
A worked example: the logo exists, but the grid spins
Imagine an owner needs to select an existing logo for a service page. Grid view spins, but list view finds the logo and its file URL opens. The public header also displays it. This is a hypothetical example, not a client result or a test of a broken Webless library.
Those checks show that this record and the tested file remain available. They do not certify every attachment, smaller size or editor integration. Uploading another copy of the logo would add a new record while leaving the original grid problem unexplained.
The useful next step is to compare the grid’s loading response and a clean browser session. If the response is an unexpected login page, investigate the session or routing path. If it is a server error, correlate the timestamp with private logs. Neither result calls for deleting the logo or restoring the entire site immediately.
Do not confuse scrolling behavior with lost media
WordPress 7.1 made infinite scrolling the default for the media grid, with a per-user opt-out described in the official media-grid development note. A different Load More or scrolling experience is not, by itself, a failed upload or evidence that an update caused the fault.
Check whether more items load when you scroll and whether searching for a known item succeeds. If loading stops at a repeatable point, give support the filters and approximate point of failure. Do not turn a personal scrolling preference into a global code change or assume an older screenshot must match the installed version.
Stop before a view problem becomes a media repair
Do not regenerate every thumbnail, change upload permissions recursively, remove database records or deactivate the live site’s entire plugin stack as a first step. These actions affect more than the visible grid. A recent migration or restore may need a database-and-files comparison; a slow dashboard may need admin performance diagnosis instead.
Before an approved repair, retain the affected attachment ID, exact view and filters, failed request evidence, recent change history and a recovery copy of the records or configuration being changed. Use staging for plugin or template isolation. Change one confirmed owner at a time, preserve the original state and agree how to roll it back.
Afterward, verify both library views, the editor chooser, the tested original and required public image sizes at desktop and mobile widths. Stop and restore the approved prior state if unrelated images disappear, new duplicates appear or public galleries change unexpectedly. For scoped WordPress repair help, send the symptom and public page URL, not login credentials in a general enquiry.