Take a photograph of a brick wall, shrink it to a thumbnail in a browser, and the mortar lines turn into a shimmering mess. The image was not compressed, nothing was lost to JPEG, and the code was three lines long. The damage happened in the resize itself, and it happens because of how the scaler samples.
Bilinear Sampling Only Looks at Four Pixels
When a browser scales an image down, the default filter is bilinear: for each pixel it needs to produce, it looks at the four source pixels nearest that position and blends them by distance. For a small reduction that is fine, because those four pixels are most of what maps onto the output pixel anyway.
Now scale a 4000-pixel-wide photo to 200. Each output pixel covers a twenty-by-twenty block of the source, four hundred pixels of real information. Bilinear still looks at four of them. The other three hundred and ninety-six are not averaged, not weighted, not considered; they are simply never read.
That is not blurring, it is aliasing. Whether a brick line survives depends on whether it happened to fall under one of the four sampled points, which changes from one output pixel to the next. Regular patterns start to beat against the sampling grid and you get moiré: the shimmer on the brick wall, the rainbow on a striped shirt, the crawling on a page of small text.
It is worth being precise about why this is not a browser bug. Sampling four neighbours is the correct, fast answer for scaling up and for scaling down a little. The failure is specific to large reductions, which is exactly the operation a resizing tool exists to perform.
The Fix Is to Do It in Steps
Scale by half. At exactly 2:1, each output pixel covers a two-by-two block and bilinear's four samples are *all four of them*. Nothing is skipped. The result is a true average.
Then do it again. And again, until one more halving would overshoot the target, and take the last short step at whatever ratio remains.
4000 to 200 becomes 4000 → 2000 → 1000 → 500 → 250 → 200. Five draws instead of one, each of them well inside the range where the filter behaves. Every source pixel now contributes to the output, because at each stage every pixel is read exactly once.
The extra cost is small and bounded: halving repeatedly means the total work is the first pass plus a quarter, plus a sixteenth, and so on, which converges to about a third more than the single pass would have been. For that you get the detail back.
This is not a clever trick, it is mipmapping, the same idea 3D graphics has used since the 1980s to keep textures from shimmering in the distance, and for the same reason. This site's resizer does it on every reduction.
What the Other Filters Do
A browser canvas gives you the first two. The rest are why desktop software still looks better on a hard downscale.
| Filter | Samples | Best for |
|---|---|---|
| Nearest neighbour | 1 | Pixel art, where blending is the enemy |
| Bilinear | 4 | Small changes and upscaling |
| Bicubic | 16 | General photographic resizing, slightly sharper |
| Lanczos | 36 or more | Hard downscales, at the cost of ringing on edges |
| Box / area average | All of them | Exact reductions, which is what halving approximates |
300 DPI is not a resolution
A JPEG carries a density field in its JFIF header and a PNG carries pHYs, and both are metadata: a note about intended physical size that changes not one pixel. An 800×600 image is 800×600 whether it claims 72 DPI or 300. What matters for print is pixels divided by inches, so a 4×6 photo at 300 DPI needs 1200×1800 pixels, and no amount of editing the DPI field will produce them. If a printer asks for 300 DPI, they are asking for enough pixels.
Enlarging Cannot Work, and Why It Sometimes Seems To
Detail that was never recorded cannot be recovered. An interpolating scaler given a 200-pixel image and asked for 800 has to invent three quarters of its output, and interpolation invents smoothly: it fills the gaps with weighted averages of what it already has. The result is larger and softer, which is the honest outcome.
Machine-learning upscalers appear to break this rule and do not. They have been trained on millions of images and produce what a plausible high-resolution version *would* look like. On faces and textures this is often convincing. On a licence plate or a line of small text it is a guess dressed up as detail, and there have been real cases of such reconstructions being mistaken for evidence.
The practical rule for anything you have the original of: resize from the original every time. Repeatedly resizing a resized copy compounds every rounding and, for JPEG, re-encodes generation loss on top of it.
Resize an image without losing the detail
Exact pixels or a percentage, stepped downscaling, and a PNG, WebP or JPG export.
The Rest of the Decisions
Resampling is the part everyone gets wrong. These are the parts everyone forgets.
Resize before you compress, not after
Shrinking a JPEG means decoding it, scaling, and encoding again, so the artefacts of the first encode get baked in and then re-compressed. Going back to the original file avoids a generation of loss.
Crop rather than stretch
If the target shape does not match the source, filling and cropping keeps the subject's proportions. Stretching to fit is the one operation everybody notices and nobody can name.
Serve two sizes, not one giant one
A 4000px hero scaled down by the browser costs the visitor the full download and the phone the full decode. `srcset` exists so the device picks a size that fits it.
Watch the alpha channel when changing format
JPG has no transparency. Converting a PNG logo with a transparent background to JPG flattens it onto something, and if nothing is chosen that something is black.
Even dimensions for video and some codecs
Most video encoders, and chroma subsampling in JPEG, work on two-by-two blocks. An odd width is legal and quietly costs you a padding row.
What a Canvas Can and Cannot Do
Resizing on a canvas has limits worth knowing before you rely on it. A canvas is bounded by memory and by a maximum area, and very large images fail differently across platforms, with mobile Safari historically the tightest. Past roughly 80 megapixels a single picture stops being safe to allocate at all.
The encoders are the browser's own, so the JPEG that comes out is not byte-identical to what a dedicated encoder such as MozJPEG would produce at the same quality setting, and it is usually a little larger. If you are squeezing the last few percent out of a hero image, a build-time encoder still beats anything a page can do.
And a canvas keeps no metadata. EXIF, the camera, the lens, the timestamp and the GPS coordinates are all dropped, because the image is decoded to raw pixels and written again from scratch. Orientation is the exception that matters: it has to be applied to the pixels before the resize, or a photo shot in portrait comes out on its side.
Frequently Asked Questions
Related Tools
Keep Reading
Rounded Image Corners: When to Use CSS and When to Bake Them In
border-radius is ignored by Outlook and dropped by most PDF exporters. Where a permanent round is the only option, and why the file must be PNG.
Why HSL Says Yellow and Blue Are Equally Light
Two colors, both hsl 50% lightness, eight to one apart in contrast. Where the sRGB gamma curve hides the difference, and how OKLCH puts it back.
Base64 Is Not Encryption: What It Does and Why It Exists
Three bytes become four characters, which is where the 33 percent size increase and the trailing equals signs come from. And why it hides nothing.