What the 150×150 Thumbnail Does in WordPress (and When to Turn It Off)

Date:

Every image you upload quietly spawns a 150×150 square. It looks like disposable clutter – but a surprising amount of WordPress is wired to expect it.

The short answer: The 150×150 thumbnail is one of the default sizes WordPress generates for every uploaded image, and it’s the square-cropped one that themes, the Media Library, and many plugins reach for by default. You can disable it in Settings > Media (set the width and height to 0), but only do that if you’re certain nothing on your site uses a square thumbnail – otherwise you’ll get stretched or missing images where a square was expected.

What the 150×150 thumbnail actually is

When you upload an image, WordPress doesn’t keep just the original – it generates a set of resized copies so a page can serve an appropriately sized version instead of a huge file. Three sizes are built in:

SizeDefault dimensionsTypical use
Thumbnail150×150 (cropped square)previews, widgets, related-post grids, some featured-image slots
Mediumup to 300×300inline post images, galleries
Largeup to 1024×1024full-width and lightbox display

The thumbnail is the odd one out: it’s hard-cropped to an exact square, while medium and large keep the original aspect ratio. That square is deliberate – grids and previews line up neatly only when every image is the same shape.

The thumbnail is the only default size that’s cropped to a fixed square – which is exactly why layouts depend on it.

Why it’s wired into so much

The 150×150 size matters out of proportion to its file size because so many things assume it exists. Theme archive and category pages use it for post previews; widgets like recent posts and comment avatars pull a small square; galleries and related-post blocks tile it; and plenty of plugins request the thumbnail size by name. Because it’s a named, predictable size, developers lean on it – which means removing it can ripple into places you didn’t expect.

When it’s safe to disable

Turning the thumbnail off is reasonable in a narrow case: a site that never shows square previews – no grid archives, no thumbnail widgets, no gallery tiles – and where you want to stop generating an extra file per upload to save disk space. If that’s genuinely your site, set the thumbnail width and height to 0 under Settings > Media, and from then on new uploads skip the square (existing images keep the copies they already made).

If you’re unsure, leave it on. The space one small square saves is tiny, and a broken grid is far more visible than a few kilobytes.

Disabling the thumbnail saves kilobytes; a layout that expected a square and didn’t get one costs you a broken page.

Common misconceptions

  • “Disabling it deletes existing thumbnails.” It doesn’t – it only stops new uploads from generating the size. Old images keep their copies until you regenerate them.
  • “It slows my site down.” The thumbnail is generated once, at upload time, not on every page load. It has no ongoing performance cost; if anything, serving a 150×150 instead of a full image is faster.
  • “Bigger is always better.” Serving a full-size image where a 150-pixel square belongs wastes bandwidth and hurts loading – the small size exists precisely so the page doesn’t over-fetch.

The short version

The 150×150 thumbnail is WordPress’s default square-cropped image size, generated for every upload and used by themes, widgets, galleries and plugins wherever a small square preview belongs. It’s cheap to keep and deeply assumed, so disabling it (width and height 0 under Settings > Media) is only safe when you’re certain nothing on your site renders a square. When in doubt, keep it – the disk space you’d save is trivial next to a broken layout.

Frequently Asked Questions

Where do I change or disable the 150×150 thumbnail?

Under Settings > Media in your dashboard. Set the thumbnail width and height to 0 to stop new uploads from generating it, or change the numbers to use a different size. The setting only affects images uploaded after the change.

Will disabling the thumbnail remove images already on my site?

No. Disabling it stops WordPress from creating the size for future uploads; every image already uploaded keeps the copies it generated. To remove or rebuild old sizes you’d use a “regenerate thumbnails” tool.

Why is the thumbnail cropped to a square when the other sizes aren’t?

Because previews and grids need a consistent shape to line up. Medium and large preserve the original proportions for in-content use, while the thumbnail is hard-cropped to a fixed square so galleries, archives and widgets tile evenly.

Does keeping the thumbnail hurt performance?

No. It’s created once at upload time, not on each page view, so it adds no ongoing load. Serving the small square where it belongs is actually faster than sending a full-size image for a tiny preview.

Can I make the thumbnail a different size?

Yes – change the width and height under Settings > Media, and decide whether it should crop to an exact size or scale to fit. Existing images keep their old thumbnails until you regenerate them, so plan a regeneration pass if you change the dimensions on a live site.

Share post:

Subscribe

Popular

More like this
Related

How to Merge Spreadsheets by URL (and Why Our Tool Reported 5 Misses That Weren’t)

Matching two spreadsheets on a URL column is the same job as matching a stock list to a price list by product code. It goes wrong in the same two places: how you clean the code, and how you count what didn't match.

Many-to-One: Why a Mapping Backlog Outgrows Its Target Taxonomy

You're mapping a messy source vocabulary onto a clean target taxonomy. The target has about 5,600 slots, so the job must be roughly 5,600 decisions — right? The backlog is already past 8,900, and still climbing.

The Fix That Didn’t Take: When a Content-Hash Gate Skips Your Code Change

You shipped a fix to how one field is computed, re-ran the pipeline across everything, and it reported a clean run. Then the consistency check still flags those records as wrong. The fix is in the code, the rebuild "ran" — and the records never changed. Your own optimisation skipped them.

Your Dedup Scan Is Over-Counting — Because It Forgot What You Already Fixed

The report said 80 duplicate groups still to resolve. You'd been resolving them for days. You run it again after a big batch and it *still* says 80-ish. The backlog isn't stubborn — the scan is counting work you already finished.