How to Disable (or Change) Large Image Scaling in WordPress

Choosing what to upload in the first place? See our guide to WordPress featured image size, which covers the sizes core actually registers and how to find the one your theme uses.

If you’ve uploaded a high-resolution image to your WordPress site and noticed the filename now ends in -scaled.jpg, you’ve met WordPress’s large image scaling feature. Since WordPress 5.3 (November 2019), any image uploaded with a longest edge over 2560 pixels gets automatically resized down to 2560px and that smaller version becomes the one used everywhere on your site.

For most WordPress sites this is a quiet performance win. For photographers, print designers, and anyone who actually needs the full-resolution file embedded on the page, it’s an annoyance. The good news: WordPress still keeps your original file (most people don’t know this), and you can either disable scaling entirely, raise the threshold to something more generous, or just grab the original back from your uploads folder.

This guide covers all three options, when each one makes sense, and how to regenerate already-uploaded images if you change your mind later.

What Is Large Image Scaling in WordPress?

Large image scaling is a built-in WordPress feature that automatically resizes any uploaded image with a longest edge over 2560 pixels. It was added in WordPress 5.3 “Kirk” as a response to the rise of phone cameras and DSLRs producing 4000-6000px+ photos that nobody actually needed at full size on a web page.

The mechanic is simple: if you upload a 6000×4000 photo, WordPress saves both the original file (untouched, full resolution) and a scaled version (2560×1707 in this case) with -scaled appended to the filename. From that point on, every WordPress function that references the “full size” image (post thumbnails, media library, theme templates) uses the scaled version instead of the original.

Why 2560? The 5.3 dev note that introduced the feature states the default without justifying it. For what it is worth, 2560 pixels is the width of a 1440p (QHD) monitor, so a scaled image can still fill one edge to edge, and it comfortably covers any normal content column at 2x pixel density. The check is “width or height above the threshold,” so a tall portrait shot triggers it just like a wide landscape one.

Two other things happen in the same pass, and both can rewrite your file even when the threshold never fires. If the photo carries an EXIF orientation flag (portrait shots from phones usually do), WordPress rotates the pixels to match and saves that as the new full size, with -rotated in the filename when no scaling was needed. And since WordPress 6.7, HEIC and HEIF files from iPhones are converted to JPEG on upload, on hosts whose image library can read them. So an upload can come back as photo-scaled.jpg, photo-rotated.jpg, or a JPEG that went in as HEIC, and all three are the same mechanism.

Where Does WordPress Save the Original (Unscaled) Image?

This is the part most tutorials skip. WordPress doesn’t delete your original file when it scales an image. Both versions live side by side in your uploads folder.

If you upload photo.jpg at 6000×4000, your uploads folder ends up with:

• /wp-content/uploads/2026/05/photo.jpg: the untouched original
• /wp-content/uploads/2026/05/photo-scaled.jpg: the 2560px scaled version (this is what WordPress uses everywhere)
• Plus the usual thumbnail sizes (photo-150x150.jpg, photo-300x200.jpg, etc.)

If you need the original for a specific case (a print, a download, a high-DPI hero image), you can browse to the unsuffixed filename directly through FTP, your host’s file manager, or by stripping -scaled from any scaled URL. The original is still there, WordPress just isn’t showing it to you through the media library by default.

If you are working in code, you do not need to guess at filenames. wp_get_original_image_path() and wp_get_original_image_url() were added alongside the feature in 5.3 and return the unsuffixed file for any attachment ID, falling back to the normal file when the image was never scaled. The REST API exposes the same thing as media_details.original_image. The featured image on our top 20,000 sites study is a live example: it was uploaded at 2752×1536, WordPress stored a 2560×1429 -scaled.jpg as the file it serves, and original_image still points at the untouched upload.

Should You Disable Large Image Scaling?

For most WordPress sites, no. Image scaling is a performance feature that protects the site from accidental 8MB hero images, and most visitors will never see the difference between a 2560px image and a 6000px one.

Disable it if you run a photography portfolio, a fine-art gallery, a stock-photo site, a print-on-demand store, or any site where the full-resolution image is the product. For these cases the scaled version actively breaks the value of what you’re selling.

Raise the threshold instead of disabling if you want a middle ground: keep the protection from accidental 20MB uploads, but allow images up to (say) 4000px or 5000px for legitimate high-resolution needs. This is the right pick for most sites that find 2560px restrictive.

Leave it alone on standard blogs, business sites, news sites, and ecommerce shops where the visual content is supporting (not primary) and page speed matters more than pixel-perfect resolution.

How to Disable Large Image Scaling in WordPress

Four methods, from the one-liner to the no-code option:

Method 1: Disable Entirely (One Line of PHP)

Add this code snippet to your site via the Code Snippets plugin, a custom plugin, or your theme’s functions.php file:

add_filter( 'big_image_size_threshold', '__return_false' );

This uses the big_image_size_threshold filter built into WordPress core. Returning false tells WordPress to skip the threshold check entirely, so every uploaded image keeps its original dimensions going forward.

Heads-up: this only affects uploads after the snippet is active. Images you uploaded before will stay scaled. See the section on existing uploads below, because regenerating thumbnails alone will not revert them.

One more thing this does not switch off: EXIF rotation. A portrait phone photo with an orientation flag still gets rotated and re-saved as photo-rotated.jpg, with the original kept alongside it exactly as with scaling. If -rotated shows up after you disable the threshold, that is why, and it is harmless.

Method 2: Raise the Threshold Instead of Disabling

If 2560px is too small but you don’t want to remove the protection entirely, raise the threshold to a higher number. Same filter, different return value:

add_filter( 'big_image_size_threshold', function() {
    return 4000;
});

Replace 4000 with whatever maximum longest-edge value makes sense for your site. Common choices:

• 3840 is the exact 4K display width, good for sites with hero images displayed at very large sizes
• 4000 to 5000 is comfortable for photography portfolios that still want some upper bound
• 6000 to 8000 is effectively unlimited for any current camera, while still catching the occasional 20000px scan

This is the option most sites should actually pick if 2560px feels too aggressive. It keeps the safety net (a stray 100MP image won’t crash anything) while letting reasonable high-resolution uploads through untouched.

Method 3: Exempt Specific Formats (PNG, GIF) Instead of Disabling

Often the images you actually want left alone are a specific type. Screenshots, diagrams and UI mockups are usually PNG, and resampling them softens text and hairlines in a way photos never show. Animated GIFs are the bigger casualty: WordPress’s image editors only ever work on the first frame, so a GIF over 2560px comes back as a single static image. The filter receives the attachment ID, so you can skip the check for the formats that matter and keep it for everything else:

add_filter( 'big_image_size_threshold', function ( $threshold, $imagesize, $file, $attachment_id ) {
    $skip = array( 'image/png', 'image/gif' );
    if ( in_array( get_post_mime_type( $attachment_id ), $skip, true ) ) {
        return false;
    }
    return $threshold;
}, 10, 4 );

Photos and WebP files still get scaled at 2560px; PNGs and GIFs upload at whatever size they came in (their thumbnails have always been static, this keeps the full-size one moving). Edit the $skip array to taste. The 10, 4 at the end is not optional: without the 4, WordPress passes only the first argument and the callback fails.

Method 4: Disable via Plugin (No Code)

If you’d rather not touch any code, the Disable Media Sizes plugin can disable the scaled size from a settings screen. Install it, activate it, and toggle off the “scaled” size.

The same plugin also lets you disable other built-in image sizes (medium, large, etc.) if you want to slim down what WordPress generates on every upload. Worth it for sites with lots of media where you only ever use one or two image sizes anyway.

How to Update Already-Uploaded Images

Any of the methods above only affect future uploads. Existing images stay scaled, and here is the part most guides get wrong (this one included, until we read the code): regenerating thumbnails does not un-scale them.

Both WP-CLI and the Regenerate Thumbnails plugin rebuild the intermediate sizes from your original file, which is good. But neither touches the attachment’s stored file path (_wp_attached_file), so the “full size” URL WordPress hands to themes and the block editor keeps pointing at photo-scaled.jpg. You end up with sharper thumbnails and the same scaled full-size image. Automattic’s own tracker for the plugin has an open report on exactly this.

To genuinely revert existing uploads you have two options: re-upload them with the filter active, or point each attachment back at its original and then regenerate.

Option A: Point attachments back at the original, then regenerate

Save this as unscale.php and run it once with WP-CLI via wp eval-file unscale.php, after your threshold filter is in place. It only touches attachments that were actually scaled:

// Run once, with the threshold already disabled. Points each scaled attachment back at its original.
$ids = get_posts( array(
    'post_type'      => 'attachment',
    'post_mime_type' => 'image',
    'post_status'    => 'inherit',
    'posts_per_page' => -1,
    'fields'         => 'ids',
) );

foreach ( $ids as $id ) {
    $meta = wp_get_attachment_metadata( $id );
    if ( empty( $meta['original_image'] ) ) {
        continue; // never scaled
    }
    $original = wp_get_original_image_path( $id );
    if ( $original && file_exists( $original ) ) {
        update_attached_file( $id, $original );
        wp_update_attachment_metadata( $id, wp_generate_attachment_metadata( $id, $original ) );
    }
}

For every image with an original_image entry, it sets the served file back to the original, then regenerates metadata and sizes from it. With the threshold disabled, the regenerated full size is the original. The old -scaled.jpg files are left on disk, so any hard-coded links to them keep working. On a large library, run it in a screen session; it loads every attachment ID at once and processes them in sequence.

Prefer not to run code? Re-uploading the affected images does the same job one at a time. Either way, take a backup first.

Option B: Regenerate thumbnails only

If all you want is sharper thumbnails built from the original file, with the full size left as it is, the standard tools do that:

wp media regenerate --yes

Or, without shell access, the Regenerate Thumbnails plugin from Tools > Regenerate Thumbnails. Both read from the original file since WordPress 5.3, and WP-CLI leaves the scaled file in place rather than deleting it. On a large site either one takes a while, so run WP-CLI in a screen session or schedule it for a quiet hour.

“The server cannot process the image” error: what it actually means

If you landed here because an upload failed with “The server cannot process the image. This can happen if the server is busy or does not have enough resources to complete the task. Uploading a smaller image may help. Suggested maximum size is 2560 pixels,” the 2560 in that sentence is a red herring. It is fixed text in WordPress’s uploader script, not a reading of your threshold setting, and changing big_image_size_threshold will not make the message go away.

Here is what happened. Since 5.3, WordPress uploads the file and creates the attachment first, then generates the scaled copy and every thumbnail size in a second request. If that second step dies (typically a PHP memory or execution-time limit, which surfaces as a 500 or 504), the uploader retries it up to five more times, resuming from whichever sizes are still missing. Only when every retry fails does it delete the attachment it just created and show you this message. The same message also appears when the initial request dies before WordPress can record the attachment at all, for the same underlying reason. Either way the file was fine; your server ran out of room while resizing it.

Why big images run out of room: the image library has to unpack the whole picture into memory, at a minimum of four bytes per pixel, regardless of how small the file on disk is. A 6000×4000 photo needs at least 96 MB just to open, before a single thumbnail is made, and a heavily compressed 2 MB JPEG needs the same RAM as a 20 MB one if the pixel count matches.

The fixes, in the order to try them:

• Raise the memory ceiling that image processing actually uses. WordPress already bumps itself to WP_MAX_MEMORY_LIMIT (256 MB by default) for image work, so the usual advice to increase WP_MEMORY_LIMIT does nothing here. Add define( 'WP_MAX_MEMORY_LIMIT', '512M' ); to wp-config.php, and make sure PHP’s own memory_limit allows it, which may mean a host ticket. Our guide to increasing the PHP memory limit covers the php.ini and .htaccess side.
• Give the request more time. PHP’s default 30 second max_execution_time is tight for a 40-megapixel PNG on shared hosting.
• Generate fewer sizes. Every registered image size is another resize pass over the same big bitmap; the Disable Media Sizes plugin from Method 4 trims the list.
• Check which image library is in use under Tools > Site Health > Info > Media Handling. If neither GD nor ImageMagick is available, nothing can be resized at all and the fix is a host ticket.
• Upload a smaller version. Resizing to 2560px on your own computer first is the pragmatic fix when you do not control the server, and it is exactly what the message is hinting at.

Frequently Asked Questions

Wrapping Up

For most sites, WordPress’s large image scaling is a quiet win and worth leaving alone. For photography, art, and print sites where full resolution matters, the one-line filter snippet (or the format exemption, or a plugin if you don’t want to touch code) handles new uploads cleanly, and the un-scale snippet is the step every other guide leaves out for old ones. And if you’ve ever frantically searched for an unscaled original you assumed WordPress deleted: it didn’t, the file is still right there in your uploads folder under the unsuffixed filename.

While you’re optimizing image behavior, our guide on how to increase the WordPress upload size limit covers the other half of the upload story (the size limit itself), and how to speed up WordPress covers the broader performance picture.