What Is the -scaled Image in Your WordPress Media Library and Do You Still Need the Original?

You upload mountain-view.jpg. A week later you copy the image URL off a page, and it says mountain-view-scaled.jpg.

No plugin did that. Nobody renamed your file.

WordPress did it the second you hit upload, and it’s been doing it since version 5.3 landed back in 2019. Most people only find out when something breaks: a page builder pulling a softer image than expected, a WooCommerce download serving the wrong file, or a client asking why “scaled” is glued to their filenames.

Here’s what that file actually is, where your original went, and whether it’s safe to delete.

What the -scaled file actually is

When you upload an image, WordPress checks its width and height against a threshold. The default is 2560px. If either dimension goes over, WordPress makes a scaled-down copy and uses 2560 as both the max width and max height.

WordPress saves that copy right next to your original, with -scaled tacked onto the filename, and it becomes the largest of the image sizes generated for that upload.

A 4000 × 3000 photo turns into a 2560 × 1920 file called mountain-view-scaled.jpg. Aspect ratio stays intact, only the longest edge gets pinned.

One thing to be clear about: this is about dimensions, not megabytes.

A 900KB image that happens to be 3000px wide gets scaled. A 12MB image that’s 2000px wide sails right through untouched.

Why WordPress does this at all

The reasoning is spelled out in the core dev note for 5.3. Photos coming straight off a phone or camera are usually way bigger than any website needs, and a shot from an average modern smartphone easily clears 5MB.

Before 5.3, that full-resolution monster was the “full” size. Themes linked to it, lightboxes opened it, and browsers on high-density screens would sometimes grab it out of the srcset because nothing smaller was big enough to satisfy them.

Core developer Andrew Ozz addressed the tradeoff in the comments on that post. The point isn’t to save disk space. WordPress is trading a little extra storage for less bandwidth on the front end, and bandwidth is the more expensive of the two.

The storage cost is therefore deliberate. You’re meant to end up with both files on disk, so that nobody on mobile data downloads an 8MB photo to fill a 400px slot.

Where your original went

It’s still there. Same uploads folder, original filename, no suffix.

WordPress tucks the filename into the image metadata under a key called original_image, and version 5.3 added wp_get_original_image_path() so you can always find your way back. There’s a URL version too.

$path = wp_get_original_image_path( $attachment_id );

$url  = wp_get_original_image_url( $attachment_id );

None of this is surfaced anywhere in the admin, which is where the confusion usually starts.

Once a scaled copy exists, WordPress rewrites the _wp_attached_file meta to point at it. So get_attached_file() and wp_get_attachment_url() hand you the -scaled path, not the original. You have to ask for the original by name.

	What you get	Where you encounter it
wp_get_attachment_url()	The -scaled file	Media Library, front end, page builders
wp_get_original_image_url()	Your actual upload	Nowhere in the admin UI
Thumbnail / medium / large	Cut from the original	Created on upload, can be regenerated later

The part most people miss

Your thumbnail, medium, large, and every custom size your theme registers are not made from the -scaled file. They’re cut from the full-resolution original.

A comment inside WordPress core states it outright: the sub-sizes are generated from the original image, for best quality.

The reasoning came up while the feature was being built. One contributor pointed out that regenerating thumbnails from an already resized and re-encoded 2560px file can compound quality loss.

The original isn’t archive material, then. WordPress uses it as the master copy for every size it cuts later.

When you’d actually need it again

Regenerating image sizes isn’t some rare event. It happens when you switch themes and the new one registers different dimensions, add a custom size with add_image_size(), install a slider or gallery plugin that wants its own sizes, or sell full-resolution files.

The original core ticket is blunt about what happens if you throw the original away. A plugin can strip the original_image key and delete the file, but from then on WordPress has to build new sub-sizes from the resized copy instead. That leaves WordPress with less source resolution to work with, and your maximum available size is locked to whatever the threshold happened to be on the day you uploaded.

The practical consequence is that you can’t generate anything larger later. Delete your originals today, decide in two years that a redesigned full-width layout needs a 3840px hero, and the pixels aren’t there to work from.

So: keep them if full resolution is part of what you sell, if a redesign is plausible, or if these are your only copies. Delete them only if every image is backed up somewhere else, storage is genuinely tight, and you’ve taken a full backup first.

People also forget there’s a middle option here. You don’t have to choose between “keep everything” and “turn it off.” You can just change the number.

How to change or disable the threshold

The filter is big_image_size_threshold. Return a number in pixels to move the ceiling:

// Scale big uploads down to 3840px instead of 2560px.
add_filter( 'big_image_size_threshold', function () {

return 3840;

} );

Or return false to switch scaling off entirely:

add_filter( 'big_image_size_threshold', '__return_false' );

For a setting you want surviving a theme change, a site-specific plugin or a snippets plugin is safer than a theme’s functions.php. The issue isn’t functions.php itself, it’s tying a site-wide media rule to whichever theme happens to be active.

There are plugins in the WordPress repository that do nothing but toggle this filter, if you’d rather not touch code at all. Check the “tested up to” value first, since most haven’t needed an update in years.

A couple of caveats before you change anything.

This only affects new uploads. Changing the threshold doesn’t retroactively replace -scaled files that already exist. Existing attachments have to be handled separately, by regenerating sizes or re-uploading.

Check your registered image sizes. If your theme registers something wider than 2560px, the threshold quietly cuts it short. That’s a real core ticket, not a hypothetical, and it’s one of the more common causes of blurry full-width hero images.

Where this bites people in practice

Downloadable products. If a download workflow pulls the attachment’s standard Media Library URL, it may resolve to the -scaled file rather than the original. Worth testing before you sell full-resolution files that way, because the customer may receive a 2560px image and no error message.

Page builders. Some builders read the attachment’s main WordPress URL, which means “full size” in their UI can still hand you the scaled file. If a background looks softer on the site than it does on your desktop, check the rendered URL before blaming the builder.

Filenames. Descriptive filenames help image search, and -scaled doesn’t help anything. It won’t wreck your rankings, but if you name files carefully it’s an irritation worth knowing about.

Constructed URLs. Imports and integrations that build image URLs from the original filename won’t account for the -scaled suffix, so they request a path WordPress isn’t serving. This shows up in CSV product imports and migration scripts more than anywhere else.

PNGs used to be exempt. They aren’t anymore.

For years, WordPress skipped PNGs entirely when scaling big uploads. The ticket behind it noted that GD and ImageMagick handled very large PNGs badly, and the resized file could come out heavier than the original.

That exclusion was removed in WordPress 6.8. Core revisited the limitation after someone reported that PNG originals weren’t being converted to AVIF, and found the reason it existed had already been fixed elsewhere: the real culprit was 8-bit PNGs being written back out as 24-bit, which made them balloon. Once that was sorted, large PNGs stopped producing oversized copies, and the mime-type check was dropped from wp_create_image_subsizes().

So, on WordPress 6.8 and later, a 4000px PNG can get a -scaled copy just like a JPEG. If you’re on an older version and wondering why your wide PNGs never picked up the suffix, that’s your answer.

Scaling is not compression

WordPress’s big-image feature is about capping pixel dimensions. Resizing does re-encode the file, so the scaled copy usually lands smaller on disk, but that’s a side effect rather than the point.

It isn’t an optimization system, though. There’s no dedicated compression pass, no WebP or AVIF conversion, and your thumbnails are left exactly as WordPress cut them.

Compression is the other half of the job. ShortPixel Image Optimizer can optimize the versions WordPress generates, including the -scaled file and thumbnails, and can serve WebP or AVIF to supported browsers.

It also gives you a say over what gets touched. If you need particular master files left alone, ShortPixel’s exclusion rules can exclude every version of a matching image, while thumbnail-specific exclusions give you separate control over the generated sizes. There’s also a Resize large images option that works on full original images rather than thumbnails, with Cover and Contain modes depending on how you want the dimensions constrained.

Plenty of people use it instead of leaning on the core threshold, because they get a dimension that matches their actual layout instead of a number picked for the average WordPress site.

Not sure what WordPress has generated for an upload? ShortPixel Image Optimizer works with the different image versions WordPress creates, including generated sub-sizes and the -scaled file, so you can decide which of them get optimized. Give it a try.

The short version

The -scaled file is WordPress protecting your visitors from a 6MB photo. The original is WordPress protecting your future self.

For most sites, leaving both in place is the right call. Disk space is the cheaper of the two risks, and if you do end up switching themes you’ll want that clean source file available.

If you delete originals anyway, take a backup first and be aware that you’re fixing today’s maximum dimensions permanently.

FAQs