You shoot a 6000×4000 photo, you ship it to a card on the homepage that renders at 400×267 CSS pixels. Even at 2× DPR that is 800×534 actual pixels — 56× fewer than the source. Sending the full file forces every visitor to download 12 MB and forces their browser to scale it on the GPU on every paint. Resizing it once, ahead of time, to the dimensions you actually display gives you a smaller file, faster paint, and lower memory pressure. This tool does the resize step client-side so your originals never leave your machine.
Resizing is a pixel-count operation. Compression is a bytes-per-pixel operation. They are separate tools, they combine multiplicatively, and resize is almost always where the biggest savings come from for over-sourced images.
How to use
- Drop or pick an image — JPEG, PNG, or WebP; up to whatever your browser can decode in memory.
- Type new dimensions — exact pixels or pick a percent preset (50%, 75%, 150%, 200%).
- Keep aspect ratio — leave the lock on (default) so editing one dimension auto-fills the other. Unlock only when you want to stretch.
- Pick output format — match the source for fidelity, or convert to WebP to save bytes simultaneously.
- Resize & download — the operation runs locally on the Canvas API. No upload.
Resampling algorithms — bilinear vs bicubic vs Lanczos
When you change pixel count, the resampler has to invent (upscale) or merge (downscale) pixels. The algorithm decides how the in-between samples are weighted:
- Nearest neighbour — copies the closest source pixel. Crisp on pixel art; visibly chunky on photos.
- Bilinear — averages the 2×2 surrounding source pixels. Soft edges, fast. Browser Canvas defaults here.
- Bicubic— fits a cubic curve through 4×4 source pixels. Sharper than bilinear, mild ringing. Photoshop's "Automatic" is a variant of this.
- Lanczos — sinc-based filter over 6×6 (Lanczos-3) or 8×8 source pixels. Sharpest detail preservation, more ringing on hard edges. ImageMagick and Sharp default to this for downsampling.
- Mitchell-Netravali — bicubic with hand-tuned constants for photographic downscaling. Common in pro pipelines.
Browsers expose only what their Canvas implementation provides — typically a bilinear or bicubic variant via ctx.imageSmoothingQuality = "high". For pixel-perfect Lanczos at build time, prefer Sharp or libvips.
Downsampling and aliasing
When you shrink an image more than 2:1 in a single pass, fine detail (text, hair, stripes) can alias into shimmer or moire patterns. The robust fix is to pre-filter with a Gaussian blur sized to the downscale ratio, then resample — this is what Sharp and ImageMagick do under the hood. The browser Canvas does not by default, which is why repeatedly drawing the same image at progressively smaller sizes looks worse than asking a proper image library to produce the target size in one step. If you see jagged edges after shrinking a high-detail source, try downscaling in two stages (e.g. 100% → 50% → 25%) or use createImageBitmap(src, { resizeQuality: 'high' }), which uses a higher-quality resampler in modern browsers.
Aspect ratio cheat sheet
| Ratio | Where it shows up | Example sizes |
|---|
| 1:1 | Avatars, Instagram, app icons | 512, 1024, 2048 |
| 4:3 | Older cameras, iPad screens | 800×600, 1600×1200 |
| 3:2 | DSLR sensors, classic photo print | 1080×720, 1920×1280 |
| 16:9 | Video thumbnails, hero banners | 1280×720, 1920×1080 |
| 21:9 | Cinematic banners, ultra-wide | 2560×1080, 3440×1440 |
srcset and responsive images
The right answer to "what size should I resize to" is usually "several sizes, served via srcset." The browser picks the smallest one that fills the layout box at the user's device pixel ratio. A typical web image gets resized to 400, 800, 1200, and 1600 wide, then served:
<img
src="hero-800.jpg"
srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w, hero-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="..."
/>
Use this tool to produce each variant, or wire Sharp into your build for fully automated srcset generation.
Common pitfalls
- Upscaling beyond the source. The resampler can invent pixels but cannot invent detail. A 200% upscale of a 400px image is blurry — accept it or use an AI upscaler (Real-ESRGAN) for synthetic detail.
- Stretching with aspect lock off. Unlocking and entering mismatched dimensions distorts the image. Always crop first if the source aspect does not match the target.
- Resizing without compressing. A resized PNG is smaller but still uncompressed. Pair resize + compress for the biggest savings.
- Forgetting the 2× DPR. A hero rendering at 400×300 CSS pixels needs an 800×600 source for retina sharpness. Resize to the intended raster size, not the CSS size.
- Aliasing on text-heavy screenshots. Documentation screenshots can develop unreadable text after aggressive downscaling. Either keep them at native size or downscale in two stages with sharpening.
Performance and SEO notes
Oversized images are one of the most common Core Web Vitals regressions. Lighthouse explicitly flags "Properly size images" when the rendered size is much smaller than the source. Resizing reduces LCP by lowering both the download time and the decode + paint time. Combine with width and height attributes on the <img> tag so the browser reserves layout space immediately, preventing Cumulative Layout Shift.
Frequently asked questions
Q: Does resizing reduce quality?
Downscaling preserves the appearance well — you are throwing away information that would not have been visible at the smaller size anyway. Upscaling genuinely degrades quality because the resampler interpolates between pixels and cannot invent texture. The sweet spot is to resize once, from the highest resolution original you have, directly to the final target.
Q: Which resampling algorithm does this tool use?
The browser's Canvas API, which is typically a bilinear or low-quality bicubic implementation depending on engine. For high-end resampling (Lanczos, Mitchell-Netravali), use Sharp, libvips, or ImageMagick on the server side — the quality difference is visible on detailed photographs at large scale changes.
Q: What is aspect ratio lock?
With the lock on, editing the width auto-computes the matching height (and vice versa) so the image keeps the same width-to-height proportion. Unlock it only when you intentionally want to stretch — usually you don't. To change the aspect, crop first, then resize.
Q: How does this compare to ImageMagick or Sharp?
ImageMagick and Sharp run server-side, support Lanczos and Mitchell-Netravali out of the box, batch-process thousands of files, and integrate with build pipelines. This tool is for interactive one-offs and visual tuning where privacy matters and a single file at a time is enough.
Q: Is there a file size limit?
No hard limit, but very large images can exhaust browser memory — a 50 MP photo decodes to ~200 MB of RGBA pixels. If you hit a tab crash, downscale in two passes or use a desktop tool for the first reduction.
Q: Should I resize for retina (2× DPR)?
Yes. A card displayed at 400 CSS pixels wide needs an 800 px source for retina sharpness. Best practice is to produce 1× and 2× (sometimes 3×) versions and let srcset pick the right one per device, avoiding both blurry retina images and wasted bandwidth on low-DPR screens.
Related guides
SVG Optimization for Web Performance: Tips and Techniques
SVGs are XML, so they compress well — but the default export from Figma is bloated. Manual cleanups, SVGO, inline vs external trade-offs, and the accessibility attributes worth keeping.
Image Optimization for Web Developers: Formats, Tools, and Techniques
JPEG vs PNG was the question in 2012; today it is WebP vs AVIF, plus srcset, lazy loading, and SVG inlining. The optimizations that actually move Largest Contentful Paint.
Image Compression vs. Resizing: Picking the Right Optimization for Web Performance
Compression shrinks bytes per pixel; resizing shrinks the pixel count. When each wins, when you need both, and how srcset plus AVIF tie it together in a real responsive image setup.