WordPress Image Sizes and Thumbnails

Learn why one WordPress image upload can create several files and how themes and plugins select them.

5 min read

  • Guide
  • Intermediate
  • 5 minutes read
  • Reviewed August 5, 2026
  • WordPress media

One image upload can create several physical image files.

WordPress generates these sub-sizes so themes, blocks and browsers can request a file closer to the dimensions required by a particular layout. This improves performance when the correct size is selected.

Original and Generated Files

The uploaded file is the original attachment file. WordPress then generates registered image sizes when the source is large enough.

Core settings commonly include:

  • Thumbnail.
  • Medium.
  • Large.

WordPress and the editor also use additional internal sizes. Themes and plugins can register more using WordPress APIs.

The attachment metadata stores filenames, dimensions and MIME information for generated sizes.

Maximum Dimensions vs Exact Crops

Medium and large settings usually define maximum width and height while preserving aspect ratio.

A thumbnail can be configured to crop to exact dimensions. Cropping removes parts of the image to match the target ratio. A hard crop should be used only when the visual composition remains acceptable.

Custom sizes can also be registered as proportional or cropped variants.

Very Large Images

WordPress can scale down images above a configurable large-image threshold and use the scaled version for ordinary display while retaining information about the original.

This protects sites from accidentally serving enormous camera files, but it is not a replacement for a deliberate media workflow. Uploading an unnecessarily large original still consumes transfer, storage and processing resources.

Themes and Plugins Add Sizes

A theme may need specific dimensions for cards, headers or featured images. Ecommerce, gallery and page-builder plugins may add their own sizes.

Changing themes does not automatically remove old generated files. It can also introduce new size requirements that existing attachments do not yet have.

Use a tested regeneration process when new sizes must be created for old uploads.

Choosing a Size in the Editor

When an image is inserted, the block or media selector may allow a registered size to be chosen. The visible width can still be controlled by layout settings or CSS.

The selected image file and the displayed CSS size are different concepts. Stretching a small file can look blurred. Loading a full-size file into a small card wastes bandwidth.

Cropping and Art Direction

Automatic crops cannot understand the subject of every image. A portrait may lose a face when converted into a wide card ratio.

For important contexts, consider:

  • Focal-point controls.
  • Dedicated editorial crops.
  • Different source images for different layouts.
  • CSS object positioning.
  • A media-management tool that records crop intent.

Responsive image selection changes resolution, but not necessarily composition. Art direction may require separate assets or the HTML picture element.

Storage Implications

Every additional registered size can multiply storage consumption. A library with thousands of images and many generated variants can become much larger than the number of visible attachments suggests.

Review image sizes before adding another plugin-generated variant. Remove obsolete registrations carefully and plan cleanup only after confirming that no templates depend on those files.

Changing Media Settings

Changing Settings → Media affects future uploads. Existing images are not automatically recreated to match the new values.

Use a reputable regeneration tool or WP-CLI workflow on staging, with a backup, before processing a large production library.

Frequently Asked Questions

Why do I see many files for one image?

They are generated sub-sizes used for different layouts and responsive delivery.

Does deleting an attachment remove its thumbnails?

Normal WordPress deletion should remove known generated files. Orphaned files can remain after failed processes, manual changes or custom systems.

Will changing the thumbnail size update old images?

No. Existing attachments usually require regeneration.

Applying WordPress Image Sizes and Thumbnails in a Real WordPress Project

Consider the source asset, WordPress attachment record, generated files and every public use of the media. Accessibility, licensing, storage, performance and deletion safety should be reviewed together.

A connected concept is WordPress Media Settings. Reading the two together helps separate the immediate task from the wider WordPress responsibility.

A useful implementation begins by writing down the current state, the intended outcome and the evidence that will prove the change worked. This prevents a configuration screen, plugin recommendation or code snippet from becoming the entire strategy.

A Practical Example

Imagine a team making this decision for a production WordPress site. The useful question is not only “Can WordPress do this?” but “Which layer owns it, who maintains it, what data does it affect and how will we verify it after an update?”

Write the answer in operational terms. Name the content, user, setting, file, API or service involved. Then identify what should remain true if the theme changes, a plugin is replaced or the site is migrated.

Questions to Ask

  • What user or system problem does this solve?
  • Which WordPress layer owns the behaviour?
  • What data is created or changed?
  • Who may perform the action?
  • What can fail, and how will that failure be visible?
  • How is the result tested after updates?
  • What is the migration or removal path?

Follow the Complete Media Lifecycle

A media decision begins with the source file and continues through upload, attachment metadata, generated derivatives, delivery, reuse, replacement and deletion.

Review visual quality, accessibility text, licensing, dimensions, file weight, cache behaviour and every place the asset is referenced. WordPress can track an attachment record, but it cannot always identify every use created by themes, custom fields or external systems.

Official Reference Context

The WordPress Media Library Documentation is the primary version-specific reference for this topic. Use the current documentation to verify interface labels, supported APIs and behaviour before applying instructions to a production site.

How to Verify the Result

  • Check the original file, generated sizes and frontend delivery.
  • Verify alternative text, captions, credits and direct-file visibility.
  • Search for references before replacing or deleting the attachment.

Sources and Further Reading

Continue Learning