You upload a 3840×2160 wallpaper to WordPress, copy the file URL into a download button, and a week later a reader emails you that the file they saved is named drifting-into-june-scaled.png and measures 2560px wide. Nothing errored and nothing shows up in any log, because core did this on purpose. It happens to wallpaper downloads on every site that runs stock settings.
Since WordPress 5.3, any image upload whose longest side passes the big_image_size_threshold gets scaled down to the threshold, with -scaled appended to the filename. The original stays on disk, but the attachment now points at the scaled copy, so the URL you hand out is the scaled one. The default threshold is 2560 pixels; the 5.3 dev note and the hook reference both document it. That’s a good policy for phone photos and a bad one for files whose entire purpose is to be saved at full size and set as a desktop background.
The trigger for this was Smashing Magazine’s June wallpapers post, the monthly collection they have run for over 15 years. It’s a nice freebie and, if you read the markup instead of the artwork, an engineering artifact. There are over forty wallpapers, each published in somewhere between four and twenty-one resolutions, most of them twice, with and without a calendar burned into the art. That works out to something close to a thousand individual image files in one post, and a few of the 2026 entries ship a 3840×2160 file. Push that set through a stock install and the 2560 threshold quietly rewrites your download links.
What the 2560px threshold does to wallpaper downloads
On upload, core compares the image’s longest side against the threshold. If it’s over, the resizer produces a copy capped at 2560, appends -scaled to its filename, and makes that copy the attachment file. Sub-sizes are then generated from the scaled copy instead of the original. The untouched original sits next to it in the uploads folder under the original name, unreferenced. So the download still works, the preview still looks fine, and only someone who checks dimensions notices that your 4K asset is serving as a 2.5K asset.
The fix you’ll find in most snippets is one line, add_filter( 'big_image_size_threshold', '__return_false' );, pasted into functions.php. For one deliberate upload it’s fine. As a global setting it gets expensive fast: every 4000px photo from a client’s phone stays 4000px, sub-size generation works harder on each upload, disk and backups grow, and hosts with tight Imagick memory limits tend to fall over on the first 6000px panorama. The threshold exists for a reason. It just has no way of knowing which uploads are meant to be downloaded at full size.
Scope the exception instead of disabling it
The filter hands you the file path, so you can raise the limit only for files that land in a dedicated wallpapers directory. In practice I import these through a small admin screen that sets a custom uploads subfolder via the upload_dir filter, which gives the threshold check something reliable to key off.
<?php
function bbioon_wallpaper_big_image_threshold( $threshold, $imagesize, $file ) {
if ( false !== strpos( $file, '/wallpapers/' ) ) {
return 4200; // keep 4K uploads at native size
}
return $threshold;
}
add_filter( 'big_image_size_threshold', 'bbioon_wallpaper_big_image_threshold', 10, 3 );With that in place, a 3840×2160 upload keeps its exact dimensions and filename, and every other upload on the site still gets scaled. The originals stay heavy, so this only makes sense when the file’s whole job is to be downloaded at full size.
Before importing a whole collection, do the arithmetic first. If those roughly thousand files go through the Media Library, WordPress also generates its own sub-sizes for each one, thumbnail through 2048×2048, so the set becomes several thousand files before you’ve written a word of markup, and the library grid pays for it on every page load. The Smashing URLs show the split: article previews come from files.smashing.media, while the downloads live under smashingmagazine.com/files/wallpapers/ rather than a dated uploads folder. The bulk artifacts sit outside the article pipeline. On a client site I’d do the same: keep two or three curated previews in the Media Library, push the size matrix to a static path or a bucket, and link to those files with plain URLs.
Give the files a stable, human path scheme, something like /downloads/wallpapers/2026/06/slug-2560×1440.png. Old wallpaper posts get bookmarked and hotlinked for years, and the archive entries in the June post point at asset URLs going back more than a decade, so assume any URL you publish will still be hit in 2031. Dated uploads folders make that the next developer’s problem.
