For about six months, every thumbnail on this blog was slightly soft. Not broken. Not obviously wrong. Just… fuzzy, in the way you notice out of the corner of your eye and then talk yourself out of noticing.
The layout said the thumbnail slot was 600 pixels wide. So I exported thumbnails at 600 pixels wide. That is exactly the wrong thing to do, and it took me an embarrassingly long time to work out why, because on my monitor it looked fine and on my phone it looked like a photocopy of a photocopy.
The reason is that a CSS pixel is not a device pixel. A modern phone or a retina laptop packs two or three physical pixels into every CSS pixel — that's what window.devicePixelRatio reports. So my 600-pixel image was being stretched across 1,200 physical pixels of glass, and the browser was inventing the difference. You cannot invent detail that isn't in the file. The fix was to export at 1,200 and let CSS display it at 600.
That's the mistake this guide is built around, along with the other three or four that make resized images look worse than they should. The Image Resize tool on toolz.dev does the work in your browser — the file never leaves your machine — but the tool is the easy part. Knowing which numbers to type into it is the part that actually matters.
TL;DR: Export at 2× the display size for retina screens (a 600px slot needs a 1,200px file), and never scale up — you can't add detail that was never captured. Lock the aspect ratio unless you genuinely want to distort the image. Resize before you compress, not after. Use the Image Resize tool to set dimensions, the Aspect Ratio Calculator to work out the missing side, and the Image Compressor to get the file size down afterwards. Everything runs client-side. One caveat worth knowing up front: resizing re-encodes the image, so all EXIF metadata is stripped — great for privacy, occasionally surprising.
Why Do My Images Look Blurry After Resizing?
Nine times out of ten it's one of three things, and they're all fixable.
You scaled up. Enlarging a 400×300 photo to 1600×1200 asks the software to produce twelve pixels of information for every one it has. It does this by interpolating — averaging neighbours to guess what belongs in between — and the result is soft, because the detail genuinely does not exist. Nothing short of a generative model invents it back. Always start from the largest original you have and scale down. Down is nearly lossless; up is a guess.
You ignored the pixel ratio. The mistake I described above. If the CSS box is 600×400 and the user's screen is 2×, the browser needs 1200×800 real pixels to render it crisply. Export at 2× and let the browser scale down — downscaling in the browser looks great; upscaling looks like mud.
Something else compressed it after you. You resized carefully, then uploaded to a platform that re-encoded your image at its own quality setting. Every social platform does this. You can't stop it, but you can reduce it: upload close to the platform's target dimensions so it does as little work as possible, and hand it a file that's already clean rather than one it has to fix.
What Actually Happens When You Resize an Image?
Worth understanding, because it explains most of the surprises.
A raster image is a grid of pixels. Making that grid smaller means deciding what a new pixel should be when it sits between several old ones. That decision is called resampling, and the algorithm matters:
- Nearest neighbour — grab the closest original pixel. Fast, blocky, jagged edges. Correct only for pixel art, where blockiness is the point.
- Bilinear — average the four nearest pixels. Smooth, a little soft.
- Bicubic — weigh sixteen surrounding pixels with a cubic curve. Sharper than bilinear; the sensible default in most desktop software.
- Lanczos — a windowed sinc filter over a larger neighbourhood. Best quality for downscaling, slowest, can produce faint ringing at high-contrast edges.
Browser canvas resizing sits in the bilinear-to-bicubic range and doesn't let you pick precisely — you can only ask for smoothing quality, and the HTML spec's default for that hint is "low". That's fine for the vast majority of web work and it's why the toolz.dev tool feels instant.
There is one power-user trick worth knowing. When you downscale by a large factor in a single step — say 4000px down to 400px, a 10× reduction — some browser implementations sample too sparsely and you get aliasing: shimmering edges, moiré patterns in fabric or brickwork, and lost fine detail. The workaround is stepped downscaling: halve repeatedly (4000 → 2000 → 1000 → 500 → 400) so each step only ever throws away half the pixels. If a big reduction ever comes out crunchier than you expected, that's the reason, and doing it in two passes will fix it.
What Does the Toolz.dev Resize Tool Actually Do?
I'd rather tell you exactly than have you find out later. It's a canvas-based resizer:
- Your file is read into the browser via an object URL. It is never uploaded — there's no server to upload it to.
- It's drawn onto an HTML canvas at the target dimensions.
- The canvas is re-encoded to PNG, JPEG, or WebP (quality defaults to 0.9 for the lossy formats).
- You download the result.
Three consequences follow from that, and only one of them is in most tools' marketing copy:
EXIF metadata is stripped. A canvas re-encode produces a brand-new file. Camera model, lens, capture time, and — importantly — GPS coordinates do not survive. For anything you're publishing, that's a privacy feature, and a real one: photos straight off a phone routinely carry the exact coordinates of where they were taken. If you need the EXIF (for a photography portfolio, say), resize with a tool that explicitly preserves it. If the source came straight off a camera roll, glance at the output orientation before you publish.
Animated GIFs come out as a single frame. Canvas draws one frame. There is no honest way to describe this as anything other than a limitation — if you need to resize an animation and keep it moving, this is not the tool. (I'd rather say that plainly than let you discover it after downloading.)
Locking the aspect ratio means "fit inside", not "stretch to fill". If you enter both a width and a height with the ratio locked, the image is scaled to fit within that box while keeping its proportions. So a 16:9 photo with a 1000×1000 target comes out 1000×563, not 1000×1000. It will never distort your image — but it also won't crop it to fill the square. If you need an exact square from a rectangle, you need a crop, not a resize. That distinction confuses people constantly and it's worth being precise about.
How Do Aspect Ratios Actually Work?
An aspect ratio is just width ÷ height, expressed as a pair. The math is simple and you should be able to do it in your head, because it prevents the most common resize error: squashing.
To find the missing side, keep the ratio constant:
new_height = new_width × (original_height ÷ original_width)
A 4000×3000 photo (4:3) resized to 1200 wide becomes 1200 × (3000/4000) = 900 tall. Type 1200 and 800 instead, and you've squashed a 4:3 image into 3:2 — faces get narrower, circles become ovals, and everybody can tell something's off even if they can't say what. The Aspect Ratio Calculator does this for you and reduces the ratio for you too.
Here are the ratios that keep coming up, with the math checked rather than copied:
| Ratio | Decimal | Typical use | Example size |
|---|---|---|---|
| 1:1 | 1.000 | Square posts, profile images, logos | 1080×1080 |
| 4:5 | 0.800 | Portrait social posts (max vertical space in a feed) | 1080×1350 |
| 9:16 | 0.563 | Stories, Reels, Shorts, TikTok — full-screen vertical | 1080×1920 |
| 16:9 | 1.778 | Video thumbnails, widescreen hero images, slides | 1280×720 |
| ~1.91:1 | 1.911 | Link-preview cards (the OpenGraph shape) | 1200×628 |
| 3:1 | 3.000 | Wide profile banners | 1500×500 |
| 4:1 | 4.000 | Extra-wide profile banners | 1584×396 |
One honest note on that "1.91:1" row, since it bugs me every time: 1200×628 is not actually 1.91:1. Reduced properly it's 300:157, or 1.911. The industry rounds it and everyone shrugs. It doesn't matter in practice — but if you've ever wondered why 1200×628 doesn't divide into anything clean, that's why.
Platform pixel specs change; ratios almost never do. Rather than trust a dimensions table in a blog post (including this one) for a campaign that matters, check the platform's own current spec and then use the ratio above to hit it. The shape is stable even when the numbers drift.
What Size Should Web Images Actually Be?
For a website you control — where you're optimising for Largest Contentful Paint rather than someone else's uploader — the reasoning is different and better.
Start from the CSS box, not from the image. Find how wide the image actually renders in your layout. Not the container's max width — the image's width, at the breakpoint you care about. Then double it for retina. That's your export size. Everything beyond that is bytes you're paying to ship and the user is paying to download, for zero visible benefit.
Serve more than one size. A single 2400px file is wasteful for a phone that will render it at 380 CSS pixels. srcset exists precisely for this:
<img
src="hero-1200.webp"
srcset="hero-600.webp 600w, hero-1200.webp 1200w, hero-2400.webp 2400w"
sizes="(max-width: 768px) 100vw, 1200px"
width="1200" height="675"
alt="..."
/>
The browser picks the smallest file that will still look sharp on that device. And always set width and height attributes — they let the browser reserve the space before the image loads, which is what stops the page from jumping around and wrecking your Cumulative Layout Shift score.
Resize first, compress second. This is the order people get backwards. Compressing a 4000px image and then resizing it to 800px means you spent effort optimising pixels you were about to throw away — and you likely baked compression artifacts into the pixels you kept. Cut the dimensions first, then compress what's left with the Image Compressor. Dimensions are almost always the bigger win anyway: halving both sides of an image removes 75% of its pixels before a compressor touches it. I go deeper on that in the image compression guide.
Then pick the right format. Roughly: JPEG for photographs, PNG when you need transparency or crisp text and lines, WebP for basically everything on the web because it beats both at equivalent quality. The Image Format Converter handles that step, and the image tools overview covers how the pieces fit together.
How Do I Resize an Image on Toolz.dev?
- Open the Image Resize tool. No account, nothing to install.
- Drop your image in. It loads straight into the browser. Watch the Network tab if you want proof nothing's being sent anywhere — that's a check worth running on any image tool you paste private photos into.
- Enter your target dimensions. Type the width; with the ratio locked, the height follows. Remember to double for retina if this is for a screen.
- Pick your output format — PNG, JPEG, or WebP.
- Download. Generated in your browser, straight to your disk.
If you're producing the same image at several sizes, work from the biggest original every single time. Don't resize the 1200px export down to 600px — go back to the original and export 600 from that. Each re-encode of an already-lossy file compounds the damage, the same way a photocopy of a photocopy degrades. It's a small discipline that shows up in the final result.
Frequently Asked Questions
Can I resize an image without losing quality?
Downscaling loses almost nothing perceptible — you're discarding pixel data you no longer need, and the result on screen looks sharp. Upscaling always loses quality, because the software has to interpolate pixels that were never captured, producing softness or visible artifacts. Always resize down from the largest original you have rather than up from a small one.
What size should I export images for retina screens?
Export at 2× the size the image is displayed at. If your layout renders an image in a 600×400 box, export it at 1200×800 so it stays sharp on devices with a devicePixelRatio of 2. Going beyond 2× is rarely worth the extra bytes, since the visible benefit is minimal even on 3× displays.
Does resizing an image remove EXIF data?
Yes, when resizing happens through an HTML canvas — as it does on toolz.dev — the tool re-encodes the image into a new file and EXIF metadata does not carry over. That means camera details, capture time, and GPS coordinates are all stripped. For publishing, this is a privacy benefit; if you need EXIF preserved, use a tool that explicitly supports it.
Can I resize an animated GIF and keep the animation?
Not with a canvas-based resizer. Canvas captures a single frame, so the output is a still image in PNG, JPEG, or WebP format. Resizing an animation while preserving all its frames requires a dedicated GIF processing tool.
How do I resize an image to a specific file size in KB?
File size is not something you set directly — it falls out of dimensions, format, and compression quality. Work backwards: reduce the dimensions to what the image is actually displayed at, export as WebP or JPEG rather than PNG for photographs, then step the quality down and re-check the output size. Hitting a hard target like "under 100 KB" is usually two or three passes of that loop, not one.
How do I resize an image without cropping it?
Keep the aspect ratio locked. When width and height stay in their original proportion, every pixel of the frame is preserved and only the scale changes. Cropping only becomes unavoidable when the target shape differs from the source shape — fitting a 3:2 photo into a 1:1 avatar slot means either letterboxing the empty space or cutting some of the image away.
Should I resize or compress my images first?
Resize first, then compress. Reducing dimensions removes pixels outright — halving both the width and height eliminates 75% of them — which is nearly always a bigger file-size win than compression alone. Compressing before resizing wastes effort on pixels you are about to discard and can bake artifacts into the ones you keep.
What is the difference between resizing and cropping?
Resizing changes the dimensions of the whole image, keeping all of its content. Cropping cuts away part of the image to change its framing or aspect ratio. If you need a square from a rectangular photo, resizing with the aspect ratio locked will fit the image inside the square rather than fill it — you need a crop to fill the frame.
Is there a file size limit for resizing images in the browser?
There is no server-imposed limit, because nothing is uploaded — the practical ceiling is your device's available memory. Typical photos, including large camera files, resize instantly. Extremely large images (very high-resolution scans, for example) may take a moment or, on a memory-constrained phone, fail to load.
Why does my image still look blurry after resizing to the right dimensions?
Check three things in order: whether you scaled up from a smaller original (unfixable — find a bigger source), whether you accounted for device pixel ratio (a 600px file on a 2× screen needs to be 1200px), and whether the platform you uploaded to re-compressed the image afterwards. The third is common on social media and is best mitigated by uploading at the platform's recommended dimensions.
