Effortlessly change your image dimensions and scale photos for any project right in your browser.
When you specify new dimensions, the browser's Canvas API creates a temporary drawing surface at the target size. It then maps each pixel from the original image onto the new grid using a mathematical interpolation algorithm.
Lanczos resampling — the default for high-quality downscaling — uses a sinc function over a 3×3 or wider pixel neighborhood. This produces sharp results with minimal aliasing artifacts, which is why it's favored for photographs being reduced to web sizes.
Bilinear resampling computes each output pixel as a weighted average of the four nearest source pixels. The result is softer, which actually works better when you're enlarging an image slightly (1.2×–2×), since it smooths out the blockiness that Nearest Neighbor would leave behind.
Nearest Neighbor copies the value of the single closest source pixel with no blending. This sounds crude, but it's exactly what you want for pixel art, barcode images, or any graphic where sharp edges are more important than smooth gradients.
The critical takeaway: the resampling method you choose has a more noticeable impact on output quality than the quality slider in most cases.
Rather than guessing, here are the exact pixel counts that come up repeatedly in real workflows:
E-commerce product listings — Most marketplaces request images between 1000×1000 and 2000×2000 pixels. Amazon specifically asks for at least 1600×1600 to enable their zoom feature. Shopify recommends 2048×2048 for square product shots.
Website hero banners — Full-width hero images typically target 1920×1080 (16:9) or 1920×720 (8:3 for a more cinematic crop). Keep the file under 300KB by choosing WebP format at quality 80.
Email newsletters — Most email clients handle images up to 600px wide. A common setup is 600×400 for inline images and 600×200 for header banners. Since email clients don't support WebP universally, stick with JPG or PNG.
Passport and ID photos — Country-specific, but US passport photos require 600×600 pixels minimum at 300 DPI, which translates to a 2×2 inch print. The aspect ratio must be exactly 1:1 with the head centered between 1 inch and 1⅜ inches from the bottom.
Developer documentation and technical screenshots — Retina displays benefit from 2× resolution: a 400px-wide display area wants an 800px image. This is where integer-multiple resizing with Nearest Neighbor keeps text perfectly readable.
A persistent source of confusion: people conflate these three measurements, but they control different aspects of an image.
Pixel dimensions (e.g., 3000×2000) describe how many individual color samples exist in the image. This determines screen display size at 1:1 mapping and is the primary thing you're changing when you resize.
DPI (dots per inch) is a print-related metadata value stored in the file header. It tells a printer how large to render each pixel on paper. A 3000×2000 image at 300 DPI prints at 10×6.67 inches. The exact same image at 72 DPI prints at 41.67×27.78 inches. The pixel data is identical — only the intended print size changes. For web use, DPI is irrelevant; browsers ignore it entirely and display pixels at 1:1.
File size (e.g., 2.4 MB) depends on pixel dimensions, compression format, compression quality, and image complexity. A 1000×1000 solid white PNG is roughly 1 KB. A 1000×1000 photo of a forest canopy at JPG quality 90 might be 400 KB. Same dimensions, radically different file sizes.
When your goal is to reduce file size for faster page loads, resizing (reducing pixel dimensions) is far more effective than lowering quality alone. Cutting dimensions in half reduces pixel count by 75%, which typically reduces file size by 60–80%. Lowering JPG quality from 95 to 70 might only save 30–40% at the same dimensions.
Five errors show up constantly:
1. Stretching instead of constraining. Disabling aspect ratio lock and typing arbitrary dimensions distorts the image. A 4:3 photo forced into 16:9 will look stretched horizontally. If you need a different aspect ratio, crop first, then resize.
2. Upscaling low-resolution originals. A 200×200 thumbnail enlarged to 1200×1200 will look muddy regardless of the algorithm. The information isn't there to begin with. Start with the highest-resolution source available, and always scale down rather than up when possible.
3. Resizing multiple times. Each resize pass introduces interpolation artifacts. Re-editing, saving, resizing again, and repeating degrades the image cumulatively. Plan your final dimensions, resize once, and export once.
4. Ignoring the output format. Saving a logo with sharp edges as JPG introduces compression artifacts around those edges. PNG or WebP lossless handles these cleanly. Conversely, saving a photograph as a 24-bit PNG creates a file 5–10× larger than necessary.
5. Forgetting mobile users. A 2400px-wide hero image looks fine on a desktop monitor but wastes 80% of its pixels on a phone screen at 390px viewport width. Consider serving appropriately sized images per breakpoint rather than one oversized file.
Platform requirements shift, but these are the current standards worth knowing:
| Platform | Asset | Recommended Size | Aspect Ratio |
|---|---|---|---|
| Feed (portrait) | 1080×1350 | 4:5 | |
| Story / Reel | 1080×1920 | 9:16 | |
| YouTube | Thumbnail | 1280×720 | 16:9 |
| Twitter/X | Card image | 1200×675 | 16:9 |
| Standard pin | 1000×1500 | 2:3 | |
| Event cover | 1200×628 | 1.91:1 | |
| Post image | 1200×627 | 1.91:1 |
Some workflows require more than one operation:
Scenario: You have 40 product photos at varying aspect ratios and need them all at 800×800 for a catalog grid.
Step one: use the crop tool to isolate the product from each photo, choosing a square crop for each. Then use the bulk resize tool to apply 800×800 to the entire batch. Doing these as separate steps rather than trying to force a single resize gives you control over what stays in the frame.
Scenario: A client sends you images and you need to verify their dimensions before deciding what to resize.
Use the image dimension checker to inspect the width, height, aspect ratio, and file size of each image without opening them in an editor. This tells you exactly which files need resizing and which are already close to the target.
Traditional image tools upload your file to a remote server, process it, and send the result back. This introduces three problems:
Latency — upload time scales with file size. A 15 MB RAW export takes 10–30 seconds to upload on a typical connection, and another few seconds to process and download.
Privacy — your image exists on someone else's server, even if only temporarily. For business documents, personal photos, or NDA-protected design files, this is a non-starter for many users.
Bandwidth costs — on a metered connection (mobile data, satellite internet, capped hotel Wi-Fi), uploading a large file just to shrink it defeats the purpose.
Browser-side processing eliminates all three issues. The Canvas API and OffscreenCanvas (in supported browsers) handle the resampling entirely on your device. Your image data never traverses a network. Processing time for a typical 4000×3000 JPG to 1200×900 takes roughly 200–400 milliseconds on any device manufactured in the last six years — that's faster than a single network round-trip to a server.