## Why your images look blurry, cropped, or wrong
URL: https://hub.jkdevstudio.com/knowledge-base/tutorial/wordpress-image-sizes
Updated: 2026-09-06
Summary: What WordPress does to every image you upload, why a photo looks soft or loses its subject in a card, and how to regenerate sizes after changing theme.
An image looks soft on the home page, or a card cuts somebody's head off, or the same photo looks right in one place and wrong in another. All three come from the same thing: the file you uploaded is not the file being shown.
## What happens when you upload an image
WordPress does not display your original. On upload, it makes a set of smaller copies at fixed dimensions and picks whichever one fits the slot it needs to fill. Your original stays in the [media library](https://jkdevstudio.com/wordpress-media-library-cleanup/) as the largest option.
WordPress makes three of its own by default (thumbnail, medium, large), and a theme adds more for the places it draws: a wide crop for grid cards, a square for compact lists, a tall one for portrait cards. Each of those has a size and, usually, a fixed aspect ratio.
**WordPress also shrinks the original itself, and almost nobody knows this.**
Since 5.3, an upload wider or taller than **2560 pixels** is resized down to that limit and the untouched file is kept alongside it as `-scaled`. What every copy is then generated from, and what a "full size" insert actually serves, is the 2560 pixel version. So uploading a 6000 pixel photograph does not give you a sharper site; it gives you a slower upload and the same 2560 pixel image at the end of it.
Two consequences follow, and between them they explain almost every image complaint:
**A crop discards part of the picture.** A 16:9 card crop of a portrait photograph keeps a horizontal band through the middle and throws the rest away.
**A copy cannot be bigger than the original.** Upload a 600 pixel wide image into a slot that wants 1600, and WordPress has nothing to scale up from. The browser stretches what it has, and stretching is what "blurry" means.
## How the browser chooses which copy to show
Worth understanding, because it is the piece that makes the same photo look right in one place and soft in another.
WordPress does not hand the browser one file. It writes a `srcset`, a list of every copy it has with the pixel width of each, plus a `sizes` attribute describing how wide the image will be on the page. The browser reads both, multiplies by the screen's pixel density, and picks a file.
Two things follow from that:
**A phone often asks for a bigger file than a laptop.** A 400 pixel wide card on a 3x display needs a 1200 pixel image. That is why "fine on desktop, blurry on the phone" is a real and common report rather than a strange one.
**A wrong `sizes` value makes a correct `srcset` useless.** If the page tells the browser an image will be 1200 wide and it renders at 400, the browser downloads three times more than it needed. Modern WordPress mitigates this for images below the fold: since 6.7, a lazy loaded image gets `sizes="auto"`, which tells the browser to wait until it knows the real rendered width and then choose. It only applies to images carrying `loading="lazy"`, which is why the image at the very top of a page, the one WordPress deliberately does not lazy load, is the one whose sizing still has to be right in the markup.
That top image gets one more piece of special treatment. Since 6.3, WordPress puts `fetchpriority="high"` on the first sufficiently large non-lazy image on the page, on the assumption that it is the Largest Contentful Paint element. It is a guess, and it is usually correct: it tells the browser to start that download before the ones it would otherwise queue behind.
## Upload files that are big enough
For a featured image, upload something at least 1600 pixels wide. That covers the largest crop most themes ask for, including the doubled sizes used on high resolution screens.
Past about 2560 pixels wide there is nothing to gain, for the reason in the callout above: that is where WordPress caps it anyway.
**Compress before uploading.**
A photograph straight out of a camera can be several megabytes, and the same image at 80 percent JPEG quality is a fraction of that and looks identical on screen. An image optimisation plugin does this on upload if you would rather not think about it.
## When the crop cuts the wrong part
A crop takes the center of the image. If the subject is off to one side or near the top, the center is not where the subject is.
There is no setting for this. The fix is to crop the image yourself before uploading, so the subject is already in the middle of the frame you hand over. For a featured image specifically, prepare it as a wide picture with the subject centered, and every crop derived from it lands somewhere sensible.
The one thing worth knowing: WordPress can crop a single image by hand, in the media library under **Edit image**, and that edit creates its own set of copies for that attachment. It is the right tool for one stubborn photograph and the wrong one for a habit.
## The empty rectangle problem, and what fixes it
A separate symptom that people file under the same heading: the page loads, the text is readable, and then an image arrives and shoves everything down the screen.
That is not a sizing fault. It is the browser not knowing how tall the image will be until it has it. WordPress writes `width` and `height` attributes for exactly this reason, so the browser can reserve the space from the markup, and a plugin or a template that strips them brings the problem straight back.
The next step past reserving the space is filling it with something. A **low quality image placeholder**, usually shortened to LQIP, is a deliberately tiny copy of the picture, a few kilobytes at most, shown blurred in the real image's slot until the real one arrives. The reader sees the composition and the colours immediately instead of a grey box, the layout never moves, and the technique costs almost nothing because the placeholder is smaller than most icons on the page.
Our themes ship this as an integration rather than as something you assemble, and it carries the lazy loading with it:
Image placeholders and lazy loading
**Run one lazy loading mechanism, never two.**
WordPress lazy loads images on its own, our integration does it, and most optimisation plugins do it as well. Two of them on the same image is the usual cause of a picture that never resolves out of its blur, or that flashes on scroll.
## Regenerating sizes after a theme change
The copies are made **on upload**. A new theme registers its own sizes, and every image already in your library predates them, so they are missing exactly the copies the new theme wants.
That is why a site can look right for new posts and wrong for old ones straight after a theme change.
:::steps
### Install a regenerate thumbnails plugin
Any of the well maintained ones works. They all do the same job: walk the media library and rebuild the intermediate copies.
### Run it across the whole library
Start it and leave it running. On a large library this takes a while, and it is heavy on the server, so a quiet hour is a good choice.
### Check an old post
Open a post from before the theme change and look at the same card that was wrong. It should now be sharp.
:::
**Regenerating rebuilds copies from originals that are still there.**
If a previous optimisation plugin deleted your originals to save disk space, there is nothing left to rebuild from and no plugin can recover it.
## Choosing a size when you insert an image
When you place an image in an article, the block sidebar has a size selector. The default is usually right. Two cases where it is not:
A large photograph you want at full width, where a smaller copy would be stretched. Choose the largest option.
A small decorative image, where the full size file is much larger than the space it occupies. Choose a smaller one and save the reader the download.
## Common questions
Can I change the dimensions the theme uses?
They are set in code, so changing them means a [child theme](/knowledge-base/hooks-filters/child-themes-and-overrides) and a regeneration run afterwards, and it is rarely the right answer because the sizes exist to fit a layout designed around those ratios.
Should I use WebP or AVIF?
Yes for WebP, which is smaller than JPEG at the same quality and supported everywhere, and AVIF is smaller again with support now broad enough to serve first and fall back from. Neither is something to convert a library by hand: an optimisation plugin, or our placeholder integration, offers the modern format inside a `` and leaves what you uploaded as the fallback.
My image looks fine on desktop and blurry on a phone
Phones usually have a higher pixel density than laptops, so a 400 pixel wide card there asks for a file two or three times that width, and an original that was too small runs out of copies at exactly that point.
How many copies of each image am I storing?
One per registered size plus the original and, for anything over 2560 pixels, the untouched `-scaled` source as well. It adds up quickly on a media heavy site and is worth knowing before you choose a hosting plan by disk space.
Images still look wrong after regenerating
Right click the image, open the browser inspector and read the file name being served, because it ends in the dimensions of the copy in use, such as `-800x450`. Compare that to the space it fills: a copy smaller than its slot is the blurry case, and a name with no dimensions at all means the original is being served because no suitable copy exists. While you are there, read the `sizes` attribute too: a value far larger than the space the image occupies means the browser is being told to fetch more than it needs.