How to Disable WordPress -scaled Images (big_image_size_threshold)

Add a filter on big_image_size_threshold that returns false and WordPress stops creating -scaled copies on upload. Return a number instead and you raise the cap rather than removing it. Both go in functions.php or a small mu-plugin, and both only affect uploads made after the filter is active.

// Disable the cap entirely — no -scaled copies at all.
add_filter( 'big_image_size_threshold', '__return_false' );

// Or just raise it. Longest edge, in pixels.
add_filter( 'big_image_size_threshold', function () {
    return 3840;
} );

What WordPress is actually doing

Since WordPress 5.3, every upload gets measured on its longest edge. If that edge is larger than big_image_size_threshold — 2560px out of the box — WordPress re-encodes the image down to that limit, saves it as your-photo-scaled.jpg, and rewrites the attachment metadata so the full size now points at the scaled copy.

Your original is not deleted. It stays on disk under its original filename, recorded in the attachment metadata, and reachable in PHP through wp_get_original_image_path(). But nothing on the front end serves it. Not the block editor, not srcset, not the media library preview. It sits there as an archive copy.

Everything downstream is then generated from the scaled file, not from what you uploaded:

Size	Source it is built from
full	the -scaled copy
large, medium_large, medium, thumbnail	the -scaled copy
Custom sizes from add_image_size	the -scaled copy
Theme and plugin sizes, e.g. woocommerce_thumbnail	the -scaled copy
srcset candidates	the -scaled copy

That single fact is why this catches so many people out.

Why this is the usual cause of “my sharp image looks soft”

Two things happen at once, and only one of them is obvious.

The obvious one is resolution. You upload a 4000px photo for a full-width hero. WordPress hands the browser 2560px. On a standard display filling a 1600px container, nobody notices. On a 2x retina screen that container wants roughly 3200 real pixels, gets 2560, and the browser upscales the gap. Soft edges, mushy detail, text inside the image going fuzzy.

The less obvious one is re-encoding. The -scaled copy is not a lossless crop of your file. WordPress decodes your upload, resizes it, and re-compresses it at its own JPEG quality setting. If your original was already a compressed JPEG out of Lightroom or a phone, that is a second-generation encode: compression artifacts on top of compression artifacts. Fine detail, film grain, and flat gradients take the worst of it. You can see this even when the pixel dimensions look adequate.

Confirm it before you change anything. Open the image in a new tab and read the filename in the URL. -scaled.jpg means the cap fired. A dimension suffix like -1536x1024.jpg means something different — srcset picked an intermediate that was too small, and the threshold filter will not help you there.

On the server:

find wp-content/uploads -name '*-scaled.*' | wc -l

If that number is large, the cap has been shaping your whole library.

You can also drop a file into the disable scaled images tool to see whether a given source would trip the threshold and at what dimensions the scaled copy would land, before you commit to a setting.

The honest trade-off

Most articles tell you disabling the cap costs disk space. That is backwards, and it is worth being precise about.

Disk usage per image goes down slightly. With the threshold on, WordPress stores your original and a large scaled copy. With it off, you keep only the original. One file instead of two.

Bandwidth and page weight go up, sometimes a lot. With the cap off, full is your untouched upload. Anything that links or renders the full size — a lightbox, a gallery plugin, a “view original” link, a theme that requests full for hero images — now ships a file that could be 6MB instead of 900KB. On mobile that is a real Largest Contentful Paint problem, and image CDNs will not always save you because some of them pass through above a size limit.

Memory during upload goes up. Resizing a 6000px image in PHP takes considerably more memory than a 2560px one. On cheap shared hosting with a low PHP memory limit, disabling the cap is a plausible way to start getting failed uploads or partially generated thumbnails. Raising the threshold to 3840 rather than removing it is the safer version of the same change.

Which is why the reasonable default for most sites is to raise the number, not remove it. Removing it is correct when you are serving images that genuinely need full resolution: print-quality galleries, product zoom, architectural photography, anything where a user is expected to inspect the original.

Applying the change properly

1. Put the filter somewhere it survives. functions.php in a child theme works. A one-file mu-plugin is better, because a theme switch cannot silently undo it.

<?php
/**
 * Plugin Name: Raise big image threshold
 */
add_filter( 'big_image_size_threshold', function () {
    return 3840;
} );

2. Re-upload the affected images. This is the step people skip and then conclude the filter did not work. The threshold is evaluated once, at upload. Existing attachments keep their old metadata forever. Delete the attachment and upload it again, then fix the references in your posts.

3. Do not expect thumbnail regeneration to rescue anything. wp media regenerate via WP-CLI rebuilds intermediate sizes from whatever the metadata calls the full file — which for an already-capped image is the -scaled copy. It cannot restore detail that was discarded. Useful as cleanup after re-uploading. Useless as a fix on its own.

4. Check the result, do not assume it. After re-uploading, open the image on the front end and read the filename again. No -scaled means the filter is live.

When disabling is the wrong move

If your source images are already under 2560px and they still look soft, the threshold was never involved. The problem is that the display box is larger than the pixels available, and the answer is a bigger source file or a smaller container — not this filter.

If the served filename carries a dimension suffix rather than -scaled, srcset chose a small candidate. That is usually a mismatch between your theme’s declared content width and the box the image actually renders in. Turning off the cap changes nothing about it.

And if a plugin is rewriting your src to an optimizer or CDN proxy, none of this applies until you check what that proxy is serving. Compare what WordPress should be generating against what the browser actually loads; when those disagree, look at what sits between them.