What happens when WordPress regenerates thumbnails

What happens when WordPress regenerates thumbnails is more complicated than simply creating a few smaller copies of an image again.

WordPress images can have an original file, a scaled version, several registered intermediate sizes, attachment metadata, responsive-image candidates and files created by themes or plugins. When thumbnails are regenerated, WordPress rebuilds some of those relationships from the source image according to the image sizes that are registered at that moment.

This is why thumbnail regeneration is commonly needed after changing image dimensions, switching themes, installing a plugin that registers new sizes or replacing an existing image.

But regeneration also has limitations. It does not necessarily delete every obsolete image file left behind by old sizes, it cannot create a thumbnail larger than the available source image, and cached URLs can continue showing older image content even after the filesystem has been updated.

This guide explains what WordPress actually does when thumbnails are regenerated, where image sizes come from, how attachment metadata changes, what happens to the original image, why old thumbnail files may remain on disk and what to check when regenerated images still appear wrong.

What does “thumbnail” mean in WordPress?

In ordinary conversation, a thumbnail means a small image.

In WordPress, the term is slightly misleading because WordPress can generate many different image sub-sizes, not just the size literally called thumbnail.

For example, one uploaded image might produce:

photo.jpg
photo-150x150.jpg
photo-300x200.jpg
photo-768x512.jpg
photo-1024x683.jpg
photo-1536x1024.jpg

These are generally called:

image sub-sizes
intermediate image sizes
generated image sizes
thumbnails

depending on the context.

The original image is the source

Suppose you upload:

mountain.jpg

Dimensions:
2400 × 1600

WordPress may use that image as the source from which it generates smaller versions.

A simplified structure might become:

mountain.jpg
├── mountain-150x150.jpg
├── mountain-300x200.jpg
├── mountain-768x512.jpg
└── mountain-1024x683.jpg

The smaller files are not separate Media Library attachments.

They normally belong to the same attachment record.

One attachment can therefore represent many physical files

Inside the WordPress database you may have:

Attachment ID:
842

while the filesystem contains several related files.

Conceptually:

Attachment ID 842
        ↓
Original image
        +
Thumbnail
        +
Medium
        +
Medium Large
        +
Large
        +
Theme sizes
        +
Plugin sizes

This distinction becomes essential when regenerating thumbnails.

Where do WordPress image sizes come from?

Some image sizes are provided by WordPress itself.

Typical core sizes include:

• thumbnail;
• medium;
• medium_large;
• large.

The exact registered sizes available on a site can also include sizes introduced by themes and plugins.

The Media settings control several core sizes

WordPress provides dimensions under:

Settings
→ Media

These settings traditionally include dimensions for:

• Thumbnail size;
• Medium size;
• Large size.

If those settings change, images uploaded afterward can receive different generated dimensions.

Changing Media settings does not automatically rebuild old images

Suppose Medium was originally:

300 × 300

and you change it to:

600 × 600

Images uploaded tomorrow can use the new configuration.

Images uploaded three years ago do not necessarily receive a new 600-pixel version merely because the setting changed.

That is one of the primary reasons thumbnail regeneration exists.

Themes can register additional image sizes

A theme may need dedicated dimensions such as:

hero
card
archive-thumbnail
featured-large

Developers can register image sizes using WordPress APIs such as add_image_size().

For example:

add_image_size(
    'article-card',
    640,
    360,
    true
);

This registers an image size called:

article-card

with dimensions:

640 × 360

and hard cropping enabled.

Plugins can register image sizes too

An ecommerce plugin might create:

product-thumbnail
product-gallery
product-large

A gallery plugin might register:

gallery-small
gallery-preview

A page builder may introduce additional dimensions for its components.

A mature WordPress installation can therefore have considerably more image sizes than the four obvious core names.

See what sizes actually exist before regenerating

TheOneWP Image Sizes List can display the image sizes currently registered in WordPress, including their dimensions and crop configuration.

This is useful before regeneration because it answers:

What is WordPress going to try to generate?

instead of making you infer the answer from whatever collection of themes and plugins currently happens to be active.

What happens during normal image upload?

When a displayable image is uploaded, WordPress builds attachment metadata and creates appropriate sub-sizes.

The core function responsible for generating attachment metadata is wp_generate_attachment_metadata().

For image attachments, WordPress can use the registered image sizes to create the appropriate derivatives.

Attachment metadata records the generated sizes

A simplified metadata structure might look conceptually like:

width: 2400
height: 1600
file: 2026/08/mountain.jpg

sizes:
    thumbnail:
        file: mountain-150x150.jpg
        width: 150
        height: 150

    medium:
        file: mountain-300x200.jpg
        width: 300
        height: 200

    large:
        file: mountain-1024x683.jpg
        width: 1024
        height: 683

The real metadata may contain additional information, but this illustrates the important relationship.

The database does not need a separate attachment for every size

WordPress stores information about generated sub-sizes inside attachment metadata rather than creating another attachment post for:

mountain-150x150.jpg
mountain-300x200.jpg
mountain-1024x683.jpg

They are derivatives of:

Attachment 842

WordPress can retrieve this metadata later

The core wp_get_attachment_metadata() function retrieves attachment metadata for an attachment ID.

Other WordPress media functions can then use that information to locate an appropriate intermediate size.

What does regenerating thumbnails actually mean?

At a high level, regeneration means:

Existing attachment
        ↓
Find source image
        ↓
Read currently registered image sizes
        ↓
Generate required sub-sizes
        ↓
Update attachment metadata

The important phrase is:

currently registered image sizes

Regeneration works from the site’s current image configuration, not necessarily the configuration that existed when the image was first uploaded.

This is why regeneration helps after changing themes

Imagine your old theme registered:

old-card:
480 × 320

Your new theme registers:

new-card:
720 × 480

Existing uploads may not have:

720 × 480

versions because that size did not exist when they were uploaded.

Regeneration can create them from the available source image.

The same applies after installing a plugin

Suppose an ecommerce plugin introduces:

product-thumb:
450 × 450

Newly uploaded product images can receive that size automatically.

Older images may need regeneration before the corresponding sub-size exists.

Regeneration does not normally mean re-uploading the image

The attachment itself remains the same WordPress media item.

Conceptually:

Attachment ID before:
842

Attachment ID after:
842

You are rebuilding derivatives of that attachment, not creating an entirely new media record.

The original attachment URL can remain unchanged

If the source file remains:

/wp-content/uploads/2026/08/mountain.jpg

thumbnail regeneration does not inherently require changing that original URL.

Generated sub-size URLs may be created or updated around it.

The original image is generally not replaced by regeneration

Ordinary regeneration creates intermediate image sizes from the source available to WordPress.

It is not the same operation as deliberately replacing the attachment’s main file.

For that distinction, see Replacing vs. re-uploading WordPress media.

Media Replace combines replacement and regeneration

TheOneWP Media Replace handles a different workflow.

It can replace the physical content associated with an existing attachment while preserving the attachment relationship, then regenerate image metadata and sub-sizes around the replacement.

That gives you a workflow conceptually like:

Existing attachment
        ↓
Replace source image
        ↓
Remove stale generated versions
        ↓
Generate fresh image sizes
        ↓
Update metadata
        ↓
Keep attachment relationship intact

Regeneration uses the dimensions registered now

Suppose an image was uploaded when WordPress knew these sizes:

thumbnail
medium
large
old-theme-card

Three years later the site has:

thumbnail
medium
large
new-theme-card
hero-wide

Regeneration can generate sizes based on the latter configuration.

Registered sizes can be inspected programmatically

WordPress provides wp_get_registered_image_subsizes() for retrieving normalized information about currently registered image sub-sizes.

Conceptually, the result can include:

thumbnail
    width
    height
    crop

medium
    width
    height
    crop

article-card
    width
    height
    crop

Not every registered size produces a file for every image

This is a common misunderstanding.

Suppose you register:

hero:
1600 × 900

but the uploaded source is only:

800 × 600

WordPress does not simply manufacture real image detail that does not exist.

The core generation logic creates intermediate sizes only where appropriate relative to the source image.

WordPress generally does not upscale small source images into every larger size

The official documentation for wp_generate_attachment_metadata() notes that intermediate image sizes are generated when the requested intermediate size is smaller than the image.

So if you expect:

1600 × 900

from an:

800 × 600

source, regeneration will not solve the missing-resolution problem.

You need a larger source.

This explains many “regeneration did nothing” reports

Suppose a new theme expects:

featured:
1400 × 800

but your old Media Library contains photographs uploaded at:

900 × 600

Running regeneration cannot generate a proper 1400-pixel derivative from those smaller originals.

Crop mode changes the result

WordPress image sizes can use either proportional scaling or cropping.

The image_make_intermediate_size() API describes this distinction.

Soft crop

With:

crop = false

WordPress preserves the image’s aspect ratio while fitting it within the requested dimensions.

For example:

Original:
1200 × 800

Requested:
300 × 300

Possible result:
300 × 200

Hard crop

With:

crop = true

WordPress can crop the image to the requested dimensions.

For example:

Original:
1200 × 800

Requested:
300 × 300

Result:
300 × 300

Regeneration can therefore change the visible crop

Suppose an old theme defined:

card:
600 × 400
crop = false

and the new theme defines:

card:
600 × 400
crop = true

Even though the width and height names look similar, regenerated output may have different framing.

Crop position can matter too

WordPress can define crop positioning using values such as:

left
center
right

top
center
bottom

So regeneration can produce a different crop if a theme or plugin changes not only the size but also the crop position.

Changing a registered image size does not modify old files automatically

Suppose:

article-card:
600 × 400

becomes:

article-card:
800 × 500

The PHP registration changes immediately.

But an existing file:

photo-600x400.jpg

does not spontaneously transform into:

photo-800x500.jpg

A regeneration process is needed for existing attachments.

What happens to attachment metadata during regeneration?

Freshly generated sub-size information needs to be reflected in the attachment metadata.

A simplified before state might be:

sizes:
    thumbnail
    medium
    old-card

After rebuilding according to the current site configuration, metadata may instead describe:

sizes:
    thumbnail
    medium
    new-card
    hero

The exact behavior depends on the regeneration implementation being used.

Metadata and filesystem state should agree

Ideally:

Metadata says:
photo-768x512.jpg exists

Filesystem:
photo-768x512.jpg actually exists

Problems appear when those two layers become inconsistent.

Missing generated files can break image output

Suppose attachment metadata says:

medium:
photo-300x200.jpg

but somebody manually deleted:

photo-300x200.jpg

WordPress may still construct URLs around metadata that refers to a file that no longer exists.

Regeneration can help restore missing derivatives when the source image is still available.

Regeneration is therefore useful after filesystem damage

Examples include:

• generated thumbnails accidentally deleted;
• an incomplete media migration;
• files restored from a partial backup;
• image sizes lost during deployment;
• old generated files missing after storage changes.

But regeneration requires the source image

If the original or current full-size source itself is missing, WordPress has nothing reliable from which to rebuild the derivatives.

Conceptually:

Missing thumbnail
+
source exists
→ regenerate

Missing thumbnail
+
source missing
→ regeneration cannot reconstruct original detail

Does regeneration delete old thumbnail files?

Not necessarily.

This is one of the most important details.

The official WordPress documentation for wp_generate_attachment_metadata() states that although the function can be used to regenerate intermediate sizes, it does not itself check for or delete intermediate sizes previously created for the same image.

This can leave orphaned thumbnails on disk

Suppose the old site generated:

photo-500x500.jpg
photo-900x600.jpg

The current site uses:

photo-640x360.jpg
photo-1200x800.jpg

After regeneration you may end up with:

photo.jpg

Old:
photo-500x500.jpg
photo-900x600.jpg

Current:
photo-640x360.jpg
photo-1200x800.jpg

unless the regeneration tool explicitly removes obsolete files.

Regeneration and thumbnail cleanup are different operations

Think of them separately:

Regeneration
→ create the sizes currently required

Cleanup
→ remove generated files no longer required

Some tools perform both.

Core metadata generation by itself should not be assumed to perform a complete historical cleanup.

Old thumbnails can consume substantial disk space

Imagine:

20,000 original images

and a site that has accumulated:

12 obsolete image sizes

Even if every derivative is relatively small, the total storage overhead can become significant.

The number of image files can grow surprisingly fast

Suppose one uploaded image generates:

10 sub-sizes

Then:

5,000 source images
×
10 generated sizes
=
50,000 derivative files

Add several years of changing themes and plugins and the filesystem can acquire a remarkable enthusiasm for JPEG multiplication.

Deregistering a size affects future generation

WordPress provides remove_image_size() for removing custom registered image sizes.

If a plugin registered:

plugin-banner

and you remove that size registration, WordPress can stop generating it for future uploads.

Removing an image-size registration does not necessarily delete historical files

This:

remove_image_size( 'plugin-banner' );

means:

Do not treat this as a currently registered custom size.

It does not necessarily mean:

Search the uploads directory and delete
every plugin-banner image ever created.

That distinction matters during plugin removal

A plugin can disappear while thousands of image derivatives created by it remain on disk.

When cleaning up old WordPress plugins, inspect both:

• database configuration;
• generated media files.

For the broader cleanup workflow, see A WordPress plugin cleanup checklist.

Do not blindly delete files based on filename dimensions

It may seem tempting to delete:

*-300x300.jpg
*-600x400.jpg
*-1024x768.jpg

because you think those sizes are obsolete.

But those files may still be referenced by:

• old post content;
• serialized page-builder data;
• custom fields;
• theme settings;
• external websites;
• cached HTML;
• email templates.

Media cleanup deserves more care than a heroic shell wildcard at 2 a.m.

WordPress can reference image sizes dynamically

A theme might request:

wp_get_attachment_image(
    $attachment_id,
    'article-card'
);

WordPress then resolves the requested size using the attachment’s available metadata.

WordPress can find intermediate sizes from metadata

The core image_get_intermediate_size() function looks at attachment metadata to retrieve an appropriate intermediate image.

This is another reason keeping metadata synchronized with the actual generated files matters.

Regeneration can affect responsive images

Modern WordPress image output can contain:

src
srcset
sizes

A simplified example:

<img
    src="photo-768x512.jpg"
    srcset="
        photo-300x200.jpg 300w,
        photo-768x512.jpg 768w,
        photo-1024x683.jpg 1024w
    "
>

The browser can then choose an appropriate image candidate.

Newly generated sizes can change the available srcset candidates

If regeneration creates a missing:

768px

version, WordPress may have another appropriate candidate available when building responsive-image markup.

This can improve delivery efficiency when the site’s current image sizes are properly designed.

More generated sizes are not automatically better

If twenty plugins each register five arbitrary image sizes, you do not automatically gain a magnificent responsive-image architecture.

You may simply gain:

100 opportunities to fill the uploads directory.

Only generate image sizes that serve an actual presentation requirement.

Use Image Sizes List to audit registered dimensions

Image Sizes List is useful for identifying:

• core sizes;
• theme sizes;
• plugin sizes;
• dimensions;
• crop settings;
• where a particular size came from.

That makes it easier to determine which sizes are worth retaining before you regenerate a large Media Library.

Large thumbnail regeneration can be expensive

Regenerating one image is trivial.

Regenerating:

80,000 images
×
8 sub-sizes

is not.

The operation can consume:

• CPU;
• memory;
• disk I/O;
• storage;
• execution time.

Image processing is computational work

For each derivative, WordPress may need to:

1. open the source image;
2. decode it;
3. calculate dimensions;
4. resize or crop it;
5. encode the result;
6. write the file to storage;
7. update metadata.

Do that hundreds of thousands of times and even a server eventually develops opinions.

Large source images increase the cost

A:

8000 × 6000

source requires considerably more image-processing resources than:

1600 × 1200

even when the target thumbnail is relatively small.

Run large regeneration jobs in batches

For large libraries, batch processing is safer than attempting to regenerate everything in one enormous browser request.

A conceptual workflow:

Batch 1:
attachments 1–100

Batch 2:
attachments 101–200

Batch 3:
attachments 201–300

This reduces the likelihood of one timeout destroying the usefulness of the entire operation.

Command-line regeneration can be useful

WP-CLI provides media-related commands and is often better suited to large administrative jobs than a browser request.

The official WP-CLI media regenerate documentation describes the wp media regenerate command.

A typical command can look like:

wp media regenerate

Options are available for controlling which attachments or sizes are processed.

Always back up before a large regeneration

Thumbnail regeneration changes filesystem content and attachment metadata.

Before processing a substantial production library, back up:

• the database;
• the uploads directory.

TheOneWP Backup Manager can form part of a broader backup workflow before structural media operations.

Why can regenerated thumbnails still look unchanged?

Because image generation is only one part of the delivery chain.

You may successfully create a new image on disk while the browser continues displaying a cached copy.

Browser cache can preserve the old image

Suppose:

URL:
photo-600x400.jpg

previously contained version A.

You regenerate the image so the same URL now serves version B.

The browser may still have version A cached.

CDNs can preserve old image content too

A delivery chain might be:

WordPress
↓
Origin server
↓
CDN
↓
Browser

You update the origin file.

The CDN may still serve the older cached object.

Regeneration and cache invalidation are different operations

This is another useful distinction:

Regeneration:
changes or creates image files

Cache invalidation:
forces delivery systems to fetch
the updated image

Solving one does not automatically solve the other.

Cache busting can help when URLs stay the same

One strategy is to change the effective request URL with a version parameter:

photo.jpg?v=1724847821

For a deeper explanation, see WordPress image cache-busting, explained.

Media Replace needs to consider caching for this reason

Media Replace intentionally preserves an existing attachment relationship.

That makes cache handling particularly relevant because file identity may stay stable while the bytes behind the URL change.

Why do old image dimensions sometimes remain in HTML?

Not every image reference is generated dynamically.

Some post content may contain explicitly stored markup such as:

<img
    src="photo-600x400.jpg"
    width="600"
    height="400"
>

Regenerating new sizes does not necessarily rewrite every historical piece of HTML stored in the database.

Regeneration is not a global search-and-replace

Creating:

photo-800x500.jpg

does not inherently turn every occurrence of:

photo-600x400.jpg

inside posts into:

photo-800x500.jpg

Those are separate concerns.

Dynamic WordPress image functions behave differently

If a theme requests an attachment by:

attachment ID
+
image size name

WordPress can resolve the current size dynamically.

This makes the theme more resilient to changes than hardcoding one generated filename everywhere.

This is why attachment IDs matter

An attachment ID represents the logical media item.

A generated filename represents one physical derivative.

For example:

Attachment:
842

Derivative:
mountain-768x512.jpg

If your content depends on attachment identity rather than a specific derivative filename, regeneration can work much more cleanly.

What happens after replacing an image with different dimensions?

Suppose the old source was:

2000 × 1200

and the replacement is:

1200 × 1200

The possible generated image set changes.

A size that could previously be created may no longer be appropriate.

Old derivatives become especially dangerous after replacement

Imagine:

Old source:
2000 × 1200

Generated:
hero-1600x900.jpg

Then the source becomes:

1200 × 1200

If the old:

hero-1600x900.jpg

remains on disk, it contains content generated from the previous image.

A replacement workflow should therefore consider removing old derivatives before rebuilding new ones.

This differs from ordinary regeneration

A generic regeneration function may focus on:

Create current required sizes

while a replacement tool may need:

Remove derivatives belonging to previous source
+
generate derivatives belonging to new source

Metadata alone cannot tell you every historical file that exists

Attachment metadata typically describes the active image derivatives known to WordPress.

Over years of theme changes, the uploads directory may contain additional generated files no longer represented by current metadata.

This is why filesystem cleanup can be more complex than simply reading:

$metadata['sizes']

Do not delete unknown generated files without checking references

A derivative that is no longer registered may still have been embedded directly in old content.

Before aggressive cleanup, consider:

• database references;
• page-builder data;
• custom fields;
• CSS background URLs;
• external links;
• CDN paths.

What about WordPress’s scaled image?

Modern WordPress can scale very large image uploads and use the scaled version as the attachment’s working full-size image.

This means the conceptual structure can sometimes look more like:

Original uploaded image
        ↓
Scaled full-size image
        ↓
Intermediate sizes

The source WordPress uses for sub-size generation may therefore not always be identical to the untouched file originally uploaded.

WordPress keeps information about the original where appropriate

Image-editing and large-image workflows can maintain additional metadata relating to original files and backup sizes.

This is one reason manually manipulating image files inside wp-content/uploads without updating WordPress metadata can produce inconsistent results.

Do not treat the uploads directory as a dumb folder

WordPress media consists of relationships between:

attachment posts
metadata
filesystem paths
generated sizes
content references

Renaming or deleting arbitrary files with FTP can break those relationships.

Image editing can create another set of relationships

WordPress includes its own image editing interface for operations such as:

• crop;
• rotate;
• flip;
• scale.

The core image-editor interface uses attachment metadata and can keep backup information that allows edited images to be restored.

The official wp_image_editor() documentation illustrates this relationship.

Regeneration should not be confused with manual image editing

These workflows solve different problems:

Image editing:
Change visual source or crop

Regeneration:
Rebuild registered derivatives

What happens to image quality during regeneration?

Each generated derivative has to be encoded.

The final result can depend on:

• source format;
• image editor;
• compression quality;
• output format;
• WordPress filters;
• optimization plugins.

Regenerating from a good source is better than repeatedly processing derivatives

Conceptually, you want:

high-quality source
↓
thumbnail

rather than:

thumbnail
↓
another thumbnail
↓
another thumbnail

Repeated lossy processing can degrade image quality.

Image optimization can be part of the same broader workflow

TheOneWP Image Optimizer handles a related but distinct concern: reducing image weight and producing optimized formats where configured.

Thumbnail regeneration answers:

Which dimensions should exist?

Optimization answers:

How efficiently should those image files be stored and delivered?

Do not regenerate hundreds of unnecessary sizes and optimize them afterward

The more efficient order is usually:

Audit required sizes
↓
Remove unnecessary registrations
↓
Regenerate what is actually needed
↓
Optimize delivery

Otherwise you are spending CPU and disk space efficiently processing files you never needed in the first place. A triumph of optimization, technically speaking.

Can thumbnail regeneration improve performance?

Indirectly, yes.

If a theme needs a:

400 × 250

image but the only available file is:

2400 × 1500

the browser may download far more image data than necessary.

Generating an appropriate intermediate size lets WordPress serve a smaller resource.

But regeneration alone does not guarantee the right image is used

Your theme still needs to request or output the appropriate size.

Creating:

article-card-400x250.jpg

provides an option.

It does not force poorly written frontend code to stop requesting:

full-size.jpg

Frontend markup remains important

A well-designed image workflow combines:

• appropriate source dimensions;
• useful registered sizes;
• responsive image markup;
• correct layout dimensions;
• compression;
• modern formats where appropriate;
• caching.

Regeneration can increase disk use before it decreases anything

If a regeneration process creates new sizes without deleting old ones, disk consumption can actually increase.

For example:

Before:
original + 6 old sizes

After:
original + 6 old sizes + 5 new sizes

This surprises site owners who expected regeneration to be a cleanup operation.

Measure the uploads directory before and after large jobs

For large sites, record:

• number of attachments;
• number of registered image sizes;
• uploads directory size;
• available disk space;
• backup size.

Then compare after regeneration.

Low disk space can break regeneration midway

If the server runs out of disk space during a large regeneration:

some images may be regenerated
some may not

This creates inconsistent media state.

Check storage capacity before beginning.

Timeouts can create partial results too

A browser-based regeneration process may encounter:

• PHP execution limits;
• proxy timeouts;
• web-server timeouts;
• memory exhaustion;
• process termination.

Batching or command-line processing reduces several of these risks.

Permissions can prevent file creation

If PHP or the relevant processing service cannot write to the uploads directory, thumbnail creation can fail.

Check:

• filesystem ownership;
• directory permissions;
• storage mount availability;
• object-storage configuration.

Image-editor support can affect which formats work

WordPress relies on available image-processing implementations.

A particular server may support some formats better than others depending on:

• GD support;
• ImageMagick support;
• installed codecs;
• PHP configuration.

A failed size does not always mean the entire attachment is broken

You may see:

Original:
exists

Thumbnail:
exists

Medium:
exists

Custom AVIF derivative:
failed

The attachment can still exist while one generation step fails.

Verify regenerated output instead of assuming success

After a substantial regeneration, sample several attachments and confirm:

• expected dimensions exist;
• files load successfully;
• crops look correct;
• metadata matches files;
• responsive output looks correct;
• frontend layouts use the intended sizes.

Image Sizes List can help verify individual attachments

Image Sizes List can make the available image-size structure easier to inspect rather than forcing you to reverse-engineer filenames manually.

Check the actual HTTP URL too

A file existing on disk does not guarantee visitors can retrieve it correctly.

Test URLs through the real production delivery path, especially if the site uses:

• a CDN;
• object storage;
• image transformation services;
• reverse proxies.

Regenerating thumbnails on offloaded media needs extra care

If images have been moved from local disk to external storage, a thumbnail tool needs to understand that storage architecture.

Possible questions include:

Where is the source image?

Where should derivatives be written?

Who syncs new files to storage?

Who invalidates the CDN?

A generic local-filesystem assumption may not work correctly.

Do not forget staging and production differences

Your staging site may have:

different theme
different plugins
different registered image sizes

from production.

Regenerating thumbnails on staging therefore does not automatically prove that the production size registry will be identical.

For broader environment management, see WordPress staging site best practices.

Regenerate after deployment only when necessary

If a deployment introduces a new registered image size needed by existing attachments, production may need regeneration.

If the deployment changes only CSS and no image dimensions, rebuilding 50,000 attachments would mostly provide your CPU with recreational activity.

A practical thumbnail regeneration workflow

1. Back up the database.
2. Back up the uploads directory.
3. List currently registered image sizes.
4. Identify obsolete sizes.
5. Remove unnecessary registrations where safe.
6. Check available disk space.
7. Check source images exist.
8. Test regeneration on several representative attachments.
9. Verify hard and soft crops.
10. Run the full process in manageable batches.
11. Watch for processing errors.
12. Verify attachment metadata.
13. Check generated files.
14. Check frontend responsive images.
15. Purge relevant caches if URLs retain old content.
16. Review obsolete generated files separately.

When should you regenerate WordPress thumbnails?

Common reasons include:

• you changed Media Settings dimensions;
• you switched themes;
• a new theme introduced image sizes;
• a plugin introduced new image sizes;
• you changed a custom add_image_size() definition;
• generated thumbnails are missing;
• you migrated media incompletely;
• you replaced an attachment image;
• stored metadata and generated files are inconsistent.

When is regeneration probably unnecessary?

It may not be necessary when:

• only CSS display dimensions changed;
• the required image sizes already exist;
• only non-image media was changed;
• the issue is purely browser cache;
• the issue is purely CDN cache;
• the source image is too small for the requested size;
• the frontend incorrectly requests the full-size image.

Diagnose before regenerating everything

If one image looks wrong, first ask:

Is the required generated file missing?

Is the crop wrong?

Is metadata wrong?

Is frontend code requesting wrong size?

Is cache showing old content?

Is the source too small?

“Regenerate all thumbnails” should not be the WordPress equivalent of rebooting the router while refusing to look at the lights.

Common thumbnail-regeneration mistakes

Assuming regeneration deletes every obsolete image

Core metadata generation does not automatically guarantee historical thumbnail cleanup.

Regenerating before removing unwanted image sizes

You may regenerate thousands of files you were about to stop using.

Expecting WordPress to upscale tiny originals

A smaller source cannot produce every larger requested derivative.

Ignoring hard-crop changes

The new file may technically have the correct dimensions while visually cropping the wrong subject.

Ignoring disk capacity

Thousands of newly generated images consume real storage.

Running everything through one browser request

Large libraries deserve batching or command-line processing.

Assuming generated means delivered

Browser or CDN cache can still return an older object.

Deleting old files based only on dimensions

Historical content may still reference those URLs directly.

Forgetting custom plugin image sizes

A plugin may depend on a size whose purpose is not obvious from its name.

Regenerating on staging with different plugins than production

The registered size set may differ between environments.

Ignoring image metadata after filesystem manipulation

WordPress needs its database and filesystem representation to remain coherent.

WordPress thumbnail regeneration checklist

• Identify the original attachment.
• Confirm the source image exists.
• List currently registered image sizes.
• Identify which theme or plugin registered custom sizes.
• Review width and height values.
• Review hard versus soft cropping.
• Remove unnecessary custom size registrations before regeneration where appropriate.
• Back up the database.
• Back up uploads.
• Check disk capacity.
• Test a small sample first.
• Confirm expected derivatives are created.
• Confirm source images are not unexpectedly changed.
• Verify attachment metadata.
• Check frontend output.
• Check srcset candidates.
• Purge CDN caches where necessary.
• Check browser caching.
• Review obsolete derivatives separately.
• Do not delete historical files without checking references.
• Use batches for large libraries.
• Verify offloaded-media behavior separately.

Related WordPress image and media guides

For the wider WordPress image-generation, media-management and caching cluster, continue with:

• Replacing vs. re-uploading WordPress media
• WordPress image cache-busting, explained
• Keeping a WordPress media library organized at scale
• Hiding vs. restricting access to WordPress media
• WordPress staging site best practices
• A WordPress plugin cleanup checklist
• Image Sizes List
• Media Replace
• Image Optimizer
• Media Categories
• Backup Manager

Final thoughts

When WordPress regenerates thumbnails, it rebuilds image derivatives around an existing attachment according to the image sizes registered by the site at that moment.

The attachment ID can remain unchanged. The source image usually remains the logical source. New intermediate files are generated where the source dimensions allow them, and attachment metadata is updated so WordPress knows which derivatives are available.

What regeneration does not automatically guarantee is equally important.

It does not turn a small source into a genuinely larger image. It does not necessarily rewrite every old image URL stored inside post content. It does not automatically purge browser or CDN caches. And core metadata generation should not be assumed to find and delete every obsolete thumbnail left behind by previous themes or plugins.

TheOneWP Image Sizes List helps reveal what dimensions the current installation actually registers, while Media Replace uses regeneration as part of a broader file-replacement workflow and Image Optimizer addresses the separate problem of file weight and image delivery.

The safest workflow is therefore simple: understand the current size registry, remove what you genuinely do not need, back up the site, regenerate deliberately and verify both the filesystem and frontend afterward.

Because WordPress does not really have “one image.” It has one image, seven cousins, three former cousins left by an old theme, two plugin-generated variants and a browser stubbornly displaying the one from Tuesday.