Empty WordPress media library or missing thumbnails: find the right diagnosis

Distinguish an empty library from images that do not display

You open Media and the library seems empty, loading spins endlessly, or gray boxes replace photos. Yet some images still appear on the site. The first goal is to determine what is missing: the displayed results, media records or files needed for their previews.

A media record is an entry in WordPress, with a title, ID and information about the file. A thumbnail is a small version used for display. The record can exist while that variant no longer loads. Conversely, a file can remain on the hosting server without a corresponding record in the library.

This guide addresses viewing media that should already be there. If a new upload reports a prohibited format, excessive size, processing error or disk-writing error, record that message: it calls for a separate upload diagnosis. Repeating uploads will not necessarily repair the display of older media.

Prepare a comparison without changing the originals

Save or copy outside WordPress any text you are still writing. Note the name of an expected image, a page that uses it and the last date the library worked. Also keep details of any recent migration, update or storage change.

Record the WordPress version and environment type. On WordPress.com, some technical access depends on the plan; use support when files or logs are inaccessible. In a multisite network, check which site is selected in administration: each site does not necessarily display its neighbors’ media.

Do not delete any empty box. It may correspond to an image in use. The first comparisons involve no file deletion, permission changes or backup restoration. Before correcting data or files, retain an appropriate backup and have the rollback procedure clarified.

Choose between the three approaches

Start with the first approach for any empty screen: it removes display restrictions and compares available views. A forgotten filter can be corrected immediately without hosting intervention.

The second approach is suitable if the list works but the grid does not, if a post’s picker stays empty or if loading spins indefinitely. Observe the media request sent by the screen, then the response received.

The third takes priority when records are present but their images are broken, or when both views remain empty after migration. It distinguishes the requested URL, the file actually available and the data registering that media item in WordPress. Do not run all three paths as a compulsory series of repairs.

Approach 1: reset the filters

This action is performed with an account authorized to view media. Keep the initial filter or setting values; check the result using the same reference media item. Undo the test by restoring the usual selection or session if the comparison does not confirm the lead.

1. From administration, open Media, then Library. Completely clear the search. Select All media items and All dates, or their equivalents in your interface. In list view, apply filters with the designated button and return to the first results page.
2. If a plugin adds folders, categories or an author filter, also remove that selection through its interface. Note the value before changing it so that you can restore it later. A selected virtual folder does not prove that the file has moved on the server.
3. In particular, check that you are not showing only media attached to the open document or unattached items. Attached media describes an association in WordPress; it is not an inventory of everywhere an image is used.
4. When media reappears, search for your reference file using a simple part of its name. You have corrected a restricted display. If results remain empty without a filter, continue with grid and list views.

Compare the grid, list and subsequent pages

Use the view icons above the library. In the list, look for titles and rows even if their small images are broken. Existing rows show that this screen finds records; they do not guarantee that the corresponding files are readable.

If the list works while the grid keeps loading, temporarily retain the list for viewing details. Move on to the next approach to understand grid loading. This contrast is not enough to identify a particular plugin as responsible.

Do not confuse the first set of images with the entire library. In list view, browse the pages. Since WordPress 7.1, the grid and picker load media on scrolling by default. Under Users > Profile, the Infinite Scrolling preference lets you return to a load-more button; its English label is Disable infinite scrolling in the Media Library grid view. Save the profile and retry, then restore your preference if the test does not help. The option depends on upload permission, and a filter imposed by a component can override it. Older versions may behave differently.

If only subsequent images fail to appear, note that limitation. A direct file search and list pagination let you check whether it exists without loading the whole photo collection.

Compare administration and the editor’s picker

Next open a checking draft without publishing it. In an Image block, choose the media library and search for the same file. Do not perform a new upload for this comparison. If you use a page builder or product page, record precisely which picker is involved.

A normal library under Media and an empty one in a single picker points toward that editing path, its filters or requests. You can continue collecting information from the main library, but do not conclude that saving a page using this image will work.

If only your account encounters the problem, ask someone already authorized to compare the same screen. Access rules can restrict viewing. Do not share a password or grant the Administrator role just to test. An administrator should examine the actual restriction before changing it.

Approach 2: start with a usable session

This path does not change media. It needs only your account and a comparison browser. The expected result is the same reference media item returning after signing in again or using a clean profile. If nothing changes, keep that finding and inspect the request; do not repeatedly clean up the session.

1. After preserving open work, sign in again through your usual administration URL. Reopen the library from its menu rather than reusing an old tab left open for several days. Compare the same file and view. A renewed session can fix a request whose authentication is no longer valid.
2. Next try another up-to-date browser profile without additional extensions, using the same account. A private window does not necessarily exclude every extension. If the result changes, compare browser settings before changing the server.
3. This method requires neither deleting all cookies nor globally disabling security. If you change a targeted setting for this site, note its value and restore it after an unsuccessful test. When several browsers and users encounter the same fault, record the failing request instead of repeatedly signing in again.

Observe the media request that fails

In Chrome, open developer tools from the browser menu, then Network. Leave the tool open and reload only the Media screen. For a picker, reopen it after securing your draft. Look for requests appearing as loading starts; the Fetch/XHR filter helps locate data exchanges.

The classic grid uses, in particular, admin-ajax.php with the query-attachments action. Other editor paths use the REST API, a communication interface whose media routes include /wp/v2/media. Do not assume every screen uses the same route: observe the one actually requested. In Network, the Payload pane of the admin-ajax request lets you read its action: do not confuse query-attachments, which queries records, with a file upload. Change no parameter for this inspection.

Select the request and record its time, status and URL. Check Preview or Response to distinguish a media list from a login page or blocking message. Do not modify the request or paste a script into the console. Sanitized screenshots are enough to send the finding to support.

Interpret the response without confusing code and cause

A 401 status or redirect to login suggests checking authentication. A 403 indicates refusal: account rights, request protection or a firewall rule need examination. This code does not demonstrate incorrect permissions on the image directory.

A 404 on the query route calls for checking that route and its addresses. It does not mean that every photo has disappeared. A 500 or 503 error requires server logs at the recorded time. Avoid immediately concluding that memory is insufficient.

Even with status 200, examine the response: an HTML page, PHP message or application error does not replace the expected structured data. A valid but empty response calls for revisiting filters, account context and the presence of records.

Manually opening a REST URL in a new tab does not necessarily reproduce the editor’s authenticated request. That request may include a validation token, called a nonce, and parameters missing from your test. Base the diagnosis on the observed exchange without sharing cookies or tokens.

Correct only the identified component

With this evidence, ask the site maintainer to compare the request with logs and recent changes. A triggered security rule should be corrected for the legitimate call concerned, not disabled across administration. An incorrectly cached response requires correction of that cache rule.

If a component is suspected, compare its activation on an isolated copy with its own data. Disable outgoing messages, payments and other external effects. Record its initial setting, change one element, repeat the same view, then restore it if the test solves nothing.

After correction, check the grid, list and picker. A new media-library plugin may change the screen without fixing the faulty request. Keep the diagnosis focused on existing loading behavior. If records return but images remain broken, continue toward file access.

Approach 3: compare the file URL with the thumbnail URL

This path starts from a record visible in the list. It needs viewing rights, not server access. The desired result is a pair of observed URLs: the main file and the failing thumbnail. No change is necessary at this stage, so nothing should be deleted or restored to undo the comparison.

1. From the list, open the reference media item’s details and record the file URL. Open that address in a new tab. Check that you are viewing the file, not an attachment page surrounded by the theme. For an image intended to be public, also compare access while signed out; respect the restrictions intended for private content.
2. Return to the broken screen and inspect the image request in Network, using the Img filter if necessary. The requested thumbnail may have a different address from the main file. Compare the domain, directory, name and extension without randomly altering the URL to invent a supposed variant.
3. For example, the main file may open while only a resized version is missing. Conversely, the record may point to an old domain. These situations require different corrections. Keep the exact URLs and the result of opening each one before starting a repair.

Distinguish a missing file, access refusal and an obsolete URL

A 404 on an image indicates that this address does not provide the expected resource; the file may be missing, its path may have changed, or a rule may hide it. A 403 calls for an access check. Ask the host to compare the actual path, owner and permissions without imposing a universal setting or opening folders with 777.

If the site uses HTTPS but still requests an image over HTTP, record browser warnings. Depending on the resource, the browser tries an HTTPS address or blocks loading. The fix is to restore a valid secure address without globally allowing insecure content.

A CDN is an intermediary service that distributes copies of media. If files pass through that service or external storage, its address and rules form part of the diagnosis. Have the authorized origin checked before a targeted purge; clearing a cache does not recreate a missing file.

Check the size WordPress actually requests

Under Media > Library, open the imported media item’s details in List view. Note its ID and open the main file URL. Return to the screen where the thumbnail is missing. In the browser’s Network tab, record the request for the image actually selected. If the page uses responsive images, it may request a different size from the one chosen in the editor. Compare the name, HTTP code and content type of both responses.

Then have the expected size read from the metadata for the same ID. A size registered in site settings, a stored metadata entry and a file accessible at its URL are three distinct things. If the size entry is missing, check that the size is still registered and that the original dimensions allow its creation. If it exists, record the exact filename it provides and check that file. Do not infer the name from dimensions alone.

When the original responds with 200 but the derivative fails, retain the original and current metadata. First compare storage and access for that one variant. An access block can persist after successful regeneration.

Read the registered size and the stored size

With an authorized terminal, replace the copy’s path, its domain and ID 123 in the commands below. The first reads the size stored for that media item. Look for the thumbnail key under sizes, or the key actually requested by the theme. Record its file field and dimensions. The second command lists the sizes the site currently registers. These commands regenerate no files. Keep the result private. On multisite, the --url argument must identify the verified subsite.

If the entry is absent from metadata, WordPress may provide the original or another size depending on the request. A visible preview therefore does not prove that a file of the expected size exists. If the entry is present, record the URL of the derivative actually selected and check the corresponding file in origin storage. A remote storage path, media filter or image generator can change the exposed address. Ask the maintainer to reconcile that address with the expected name before moving a file.

wp --path="/chemin/recette" --url="https://recette.example.test" post meta get 123 _wp_attachment_metadata --format=json
wp --path="/chemin/recette" --url="https://recette.example.test" media image-size --format=json

Observe three causes on a copy

First case to distinguish on your copy: the original exists and the site registers a size, but its entry is absent from the media metadata. Check that dimensions and format allow generation and that no component excludes it. Targeted regeneration may then be appropriate after backup. Keep the initial metadata and file state to compare what is added.

Second case: metadata names a variant, but the corresponding file no longer responds. Compare its exact name with actual storage; do not infer that it exists from the stored entry alone. A backed-up file can be restored after comparison, or targeted regeneration can be considered. The --only-missing option never removes the need to check what was actually created by your version of WP-CLI and your storage integration.

Third case: the file exists, but a delivery or access rule prevents HTTP reading. Regeneration does not necessarily fix that rule. Have the actually requested URL, origin path and delivery-service response compared, then correct only the unjustified refusal. The final criterion remains access to the correct variant on the affected page, not merely a successful regeneration message.

Generate a single size or restore its file

If the backed-up file exactly matches the expected entry and URL, restore it on the copy first. Check its contents and a page using it. If the file must be recreated, preserve the original, variants and metadata for that ID. The following command writes one size for that media item. Replace thumbnail with the verified size if different. --skip-delete keeps old variants, but generation may write a file under the same name. Compare files and metadata before and after. If the result is unsuitable, restore only that media item’s files and data from the prepared copy.

wp --path="/chemin/recette" --url="https://recette.example.test" media regenerate 123 --image_size=thumbnail --only-missing --skip-delete

Regenerate one media item with or without SSH

This path applies only to a confirmed missing variant with a readable source. It fixes neither a grid whose request fails nor a lost original. With external storage, first have the integration’s method confirmed. Open the media details from list view: the number after post= in the editing URL is its ID. Have this ID and the correct installation confirmed. Preserve the media item’s files and metadata before any write, with a way to restore them; otherwise, have the host prepare the backup.

If WP-CLI is already available with authorized SSH access, change to this installation’s directory. The example at the end of the section regenerates the sizes of media item 123; replace 123 with the verified ID without removing it and thereby processing the whole library. The command writes immediately, without a dry run. On multisite, also select the correct subsite using --url=https://sous-site.exemple, replacing that fictional domain with its exact address. The same number may identify another media item on another site in the network.

The --skip-delete option preserves old thumbnails that may still be referenced. It does not undo changes to regenerated files or metadata: a backup is still necessary. Do not add a deletion option or automatic reference-updating option for this first targeted test.

After either path, check the record, expected thumbnail and a page using the image. If the original cannot be read or processed, stop regenerating: that cause must be solved first. If the result deteriorates, have only the files and metadata associated with that media item restored from the checking copy. Deactivating a plugin does not undo its writes. Once the operation is verified, a plugin added only for this troubleshooting can be deactivated.

Without SSH, ShortPixel’s reGenerate Thumbnails Advanced provides an individual action in its free edition. Check the name and author: its official-directory identifier is regenerate-thumbnails-advanced, different from Regenerate Thumbnails and Force Regenerate Thumbnails. The required access permits installing a plugin and managing this media item; on multisite or a managed plan, involve the person responsible if those rights are missing. The image engine must be able to process the source and the directory must accept generated files. This plugin is unnecessary for the guide’s other diagnostics.

The path below uses free edition 2.5.0. Its listing declares WordPress 4.0 and PHP 5.6 as minimums and publisher-tested compatibility up to WordPress 7.1.4; these minimums are not recommended hosting versions. Confirm the requirements of the version offered at installation time. If an optimization or external-storage plugin already handles images, check its interactions before this test, ideally on a copy. Do not add a second optimizer to regenerate a thumbnail.

1. Without SSH, open Plugins > Add New Plugin. Search for reGenerate Thumbnails Advanced, confirm ShortPixel, then install and activate only that plugin.
2. Open Tools > Regenerate Thumbnails. Under Regenerate these thumbnails, record the current selection, then select only the size confirmed missing. Leave Force regeneration unchecked to avoid replacing existing variants. Change neither dimensions nor JPEG quality for this diagnosis, then click Save Settings.
3. Leave cleanup or deletion options disabled: Delete Unselected Thumbnails, Remove non-existent images and Clean unknown metadata. These options are marked Pro in this edition; they are not necessary. Do not start the button that processes the entire library.
4. Return to Media > Library in list view. Check the title, date, file and post= number of the selected record. On that row alone, click Regenerate Thumbnails. This click triggers writing for that ID; it is not simply a preview.
5. Wait for the page to return and show its result message without clicking again or starting a second operation. If a failure occurs, record the message and check the media item before deciding whether to try again.
6. Check the variant, record and page using the image. Then restore the plugin’s temporary settings if you keep it. To undo changed files or metadata, use the targeted backup rather than deleting the media record.

wp media regenerate 123 --skip-delete

After a migration, check what was actually transferred

Compare an old and a recent media item, along with their dates and paths. If only files from one period are missing, check whether the corresponding folders were transferred. A media directory may have been customized or externalized; do not assume everything is necessarily in the same place as on the old host.

If addresses point to the old domain, have URLs stored in posts distinguished from those calculated for media and those produced by a storage service. Changing an image title or resaving permalinks does not automatically correct all three sources.

Correcting database URLs must preserve WordPress structured data. Have the maintainer perform a limited operation preceded by a backup and a dry run with a suitable tool. Do not blindly replace text in an SQL export. Check the proposed matches before any write, then verify the reference media.

Existing files are not enough to populate the library

Uploading images into a folder by SFTP does not automatically create their WordPress records. A migration may transfer files without the entries describing them. An image still visible in a post therefore does not prove that it is in the new installation’s library.

Someone who already has WP-CLI and an authorized terminal can inspect a sample of attachments. From the confirmed directory of the correct installation, the command below reads twenty attachment records with inherit status. On multisite, add --url with the verified subsite’s address.

The expected result is a list of IDs, titles and dates to compare with the library. It is not a complete inventory: older media or items with another status may not appear, and component filters may still act. A record’s presence does not prove that its file exists either.

If the expected media item is absent from this sample, continue searching the administrative list, dates and records, then the old copy’s data as appropriate. Do not import a file solely on the basis of these twenty rows. Confirm the site, the actual absence of a record and the associations to preserve before writing.

1. Check the WordPress directory and subsite with the person responsible for the environment.
2. Run this inspection without a creation or deletion command.
3. Compare an ID found with its Media record and file URL.
4. Search separately for the missing media item by its name, period and available old reference; check that a filter is not hiding it.
5. If recovery or import is necessary, start with one authorized file and a preserved copy.

wp post list --post_type=attachment --post_status=inherit --posts_per_page=20 --fields=ID,post_title,post_date --format=table

Import one file whose record is genuinely missing

This action is for a technician who already has WP-CLI and appropriate rights, preferably on a copy. It creates a new record and copies the file into this installation’s designated upload storage. It does not restore the old ID, inserted links or all page associations. In a multisite network, also select the subsite here using --url; the terminal path alone does not distinguish it.

Prepare an authorized original in a private path and check that an existing record does not already represent the same file. Compare the name, URL and known references; titles alone may differ. If the migration needs to retain old IDs and relationships, use its targeted recovery on a copy instead of this new import.

Replace /CHEMIN_PRIVE_CONFIRME/photo-temoin.jpg with the actual absolute path of the local file and adapt the title. Keep one path, without a wildcard or entire directory. Do not add --skip-copy for a private original: that option leaves the file in its current location. The deduplication option --skip-duplicates is not yet part of a stable version according to the documentation consulted; the prior check remains necessary.

The expected result is a new ID, then a verified record, file and variants. If the operation stops, look for what has already been created before trying again. To undo it on the copy, find that new ID under Media > Library and check its uses before deleting only that record and its files. Keep the private original and backup: deleting a record is a separate action from completing the import. Do not delete older media to make names match.

Without a terminal, if an authorized copy of the file is available on your computer, use Media, Add New Media File, then select that one file. Wait for upload completion and open its details to check the URL and thumbnail. This native path also creates a new record: the same duplicate, association and rollback checks apply.

1. Preserve the relevant database and files, then confirm the absence of duplicates and the expected associations.
2. From the correct installation, run the adapted single-file import below and record the returned ID.
3. Open Media, Library and find that record; check its URL, file, thumbnail and date.
4. Complete useful information, including alternative text and caption, then select the media item in a checking draft without publishing it.
5. Compare older pages separately: this import does not automatically change their references.

wp media import "/CHEMIN_PRIVE_CONFIRME/photo-temoin.jpg" --title="Photo temoin" --porcelain

Recover missing elements without replacing the current site

If a file has disappeared, look for a local copy, old storage or a backup containing that exact item. If its WordPress data is also missing, a file archive alone is not enough. Request inspection of the backup in a separate environment with a separate database and protected access.

Recover only the identified elements. Before returning a file to the same path, check that it will not overwrite a different current version. Before reintegrating data, have the necessary IDs and associations preserved without replacing other content. An old ID already reassigned on the new site must not be overwritten to force a match.

Do not restore the entire database or staging environment to recover a few thumbnails: recent posts, accounts, comments and orders could be affected. If no usable copy exists, state that limitation. Neither cache cleanup nor a plugin installed after the disappearance guarantees the return of the original media.

Confirm the result and send useful evidence

Search for the reference media item again without a filter, first in grid view and then in list view. Open its details, check the file and thumbnail, then select it in a draft. Check the preview and an already published page using it. A visible library is not enough if its images remain inaccessible to readers.

Then try a second media item from a different date to check the scope of the correction. Restore temporary settings and keep the backup until validation. Note the observed cause and retained change rather than keeping several changes whose effects remain unknown.

For support, send the affected screens, version, time, reference media item and results for the grid, list, picker and direct URL. Add the relevant request status and recent changes. Sanitize screenshots and do not share a full network export containing a private session. This evidence lets support work at the right level without repeating a series of destructive tests.