Free Image Resizer Online

How to Resize an Image

1. Select or drop an image file above.
2. Choose a preset size or enter custom width and height in pixels.
3. Toggle the lock icon to maintain or ignore the original aspect ratio.
4. Click "Resize Image" to process the image in your browser.
5. Download the resized image instantly.

What "resizing" actually does to your pixels

Resizing an image is not the same operation as cropping or compressing it. Cropping discards pixels at the edges and keeps the rest unchanged. Compressing keeps every pixel but encodes them more tightly. Resizing literally changes the pixel count: a 4000x3000 source image rescaled to 1920x1440 has to throw away most of its pixels and pick new ones to represent the same scene at a quarter of the resolution. The mathematical operation that decides which new pixels to write is called resampling, and the quality of the rescale depends almost entirely on which resampling algorithm runs.

The four resampling algorithms in common use are nearest-neighbour (pick the single closest source pixel, hard edges preserved, blocky on enlargement, the only right choice for pixel art), bilinear (linear blend of the 4 surrounding source pixels, fast and mediocre), bicubic (Keys 1981 cubic kernel over 16 surrounding pixels, the Photoshop default for decades), and Lanczos (sinc function windowed by a Lanczos kernel, sharpest output, mild ringing near hard edges, what ImageMagick and Sharp use by default for downscale). This tool sets the Canvas API's imageSmoothingQuality to "high", which Chrome and Firefox interpret as a Lanczos-class kernel on desktop and Safari interprets as a bicubic-class kernel. The browser chooses; JavaScript can ask for "high" but cannot pick the exact filter.

Downscaling and upscaling are not symmetric problems. Downscaling discards information in a controlled way; the resampler decides which details to keep and a good algorithm preserves the visible structure of the source. Upscaling adds pixels that were never sampled, and information theory (the Nyquist-Shannon sampling theorem) says you cannot recover frequencies that were not in the original signal. The best a classical resampler can do is interpolate smoothly between known samples, which always looks soft. For genuine enlargement the modern alternative is AI super-resolution (Real-ESRGAN, waifu2x, Adobe Super Resolution, Topaz Gigapixel), which hallucinates plausible detail using neural networks trained on millions of similar images. That is not what is happening here. This tool does honest interpolation.

How this tool works under the hood

The entire pipeline is the HTML5 Canvas 2D API. No external library is loaded. When you drop an image, the browser's File API hands the bytes to a new HTMLImageElement; the browser's built-in JPEG, PNG, or WebP decoder turns the bitstream into a pixel buffer. The aspect ratio is computed from the natural width and height. A fresh <canvas> element is created in memory at the target dimensions you set, and ctx.drawImage(image, 0, 0, targetWidth, targetHeight) draws the source scaled into the destination. Because the destination has different dimensions than the source, the browser invokes its resampling kernel to compute every new pixel.

Before the drawImage call, the tool sets ctx.imageSmoothingEnabled = true and ctx.imageSmoothingQuality = "high". The first flag turns smoothing on (nearest-neighbour off); the second hints the browser to use its highest-quality filter. The WHATWG canvas specification leaves the exact filter to the implementation. Chrome and Firefox on desktop use Lanczos-class kernels at "high"; Safari uses a bicubic-class kernel; mobile builds may downgrade to bilinear under memory pressure. None of this is visible to JavaScript. After the draw, canvas.toBlob(mimeType, quality) serialises the canvas to a Blob in your chosen output format: PNG (lossless DEFLATE, the quality argument is ignored), JPEG (lossy DCT at quality 0.92), or WebP (lossy or lossless at quality 0.92). The Blob becomes a downloadable object URL.

No bytes leave the tab. The image is decoded in your browser, resampled in your browser, and re-encoded in your browser. The downloaded file is generated locally and saved to your device by the browser's normal download mechanism. The only network traffic is the initial page load and the small image-resizer.js script (a few kilobytes). Switch your browser to airplane mode after the page has loaded and the resizer continues to work on any local image you select. Open DevTools' Network tab during a resize: there are zero requests carrying image data. The entire architecture is intentionally minimal because the Canvas API is already powerful enough for this job; pulling in a library would only add bytes and complexity without changing the output.

A brief history of image resampling

• Optical enlargers, the pre-digital era. Before digital photography, "enlarging" a photograph meant projecting a negative through an optical enlarger onto a sheet of light-sensitive paper. The lens did the resampling continuously, without quantisation, but with the optical limits of the lens itself. The first commercial enlargers date to the 1860s. Resampling as a mathematical operation only became a meaningful question once images existed as pixel grids rather than continuous emulsion.
• Bicubic interpolation, 1973-1981. Robert G. Rifman published a bicubic-spline image-resampling algorithm at TRW Defense and Space Systems in 1973, written for satellite-imagery rescaling. The canonical formulation came from R. G. Keys in 1981: "Cubic Convolution Interpolation for Digital Image Processing" in IEEE Transactions on Acoustics, Speech, and Signal Processing. Every imaging library that says "bicubic" today means the Keys cubic kernel evaluated over a 4x4 neighbourhood.
• Mitchell-Netravali filter, 1988. Don P. Mitchell and Arun N. Netravali published "Reconstruction Filters in Computer Graphics" at SIGGRAPH '88, introducing a parameterised family of cubic filters tunable by two coefficients B and C. The canonical "Mitchell" filter (B=C=1/3) trades a small amount of sharpness for very low ringing and became a standard default for downscale in high-end image libraries like libvips.
• ImageMagick selectable filters, 1990s. John Cristy released ImageMagick (originally 1987, public in 1990) with selectable resampling filters as a first-class feature. By the mid-1990s photographers and DTP professionals could compare Lanczos, Mitchell, Catmull-Rom, Hermite, and Gaussian on the same source image, choosing per use case. ImageMagick's -filter Lanczos is still a common recipe in production pipelines.
• HTML5 Canvas resize, 2008-2017. The WHATWG canvas specification standardised drawImage() with implicit scaling in 2008, and the 9-argument form (the one used here) has been in every browser since then. The imageSmoothingQuality attribute (low / medium / high) shipped later, Chrome 54 in 2016, Firefox 51 in 2017, Safari 11.1 in 2018. Before that, browser-side resizing was effectively bilinear-only across every implementation, even when the tool requested "high quality."
• AI super-resolution, 2018-2021. ESRGAN (Wang et al., 2018) demonstrated that generative-adversarial networks could synthesise believable detail for upscaled photos. Real-ESRGAN (Wang et al., 2021) made the technique practical for real-world inputs; waifu2x (nagadomi, 2015) had earlier tuned a CNN-based variant for anime art. Adobe Camera Raw added Super Resolution in 2021. These tools do not replace classical resampling for downscale; they target the case where you specifically want hallucinated detail rather than smooth interpolation.

Common Image Sizes

• 1920 x 1080 · Full HD, standard for web backgrounds and YouTube thumbnails.
• 1080 x 1080 · Instagram feed posts (square format).
• 1080 x 1350 · Instagram portrait posts (takes up more screen space in feeds).
• 1280 x 720 · HD, good for blog headers and presentations.
• 800 x 600 · Classic web image size, good for email newsletters.
• 400 x 400 · Profile pictures and avatar images.
• 16 x 16 / 32 x 32 · Favicon sizes for websites.

Real-world resize workflows

• Social-media platform sizing. Every social platform has preferred dimensions for feed posts, stories, banners, and thumbnails. Uploading at the wrong size means the platform crops or letterboxes on your behalf, often badly. Common 2026 targets: Instagram feed 1080x1080 (square) or 1080x1350 (portrait, currently the highest-engagement still format because it occupies roughly 25% more vertical screen on mobile feeds), Instagram Stories and Reels 1080x1920, YouTube thumbnail 1280x720, Twitter/X in-stream card 1200x675, Facebook and LinkedIn link previews (Open Graph) 1200x630, Pinterest standard pin 1000x1500, TikTok 1080x1920. Resizing once before upload guarantees the result you want; uploading raw photos leaves the choice to the platform.
• Web optimisation and Core Web Vitals. Lighthouse's "Properly size images" audit fails any image where the natural dimensions are much larger than the displayed dimensions. A hero image displayed at 1200 pixels wide but served at 4000 pixels wastes bandwidth and hurts Largest Contentful Paint, the most visible Core Web Vital. The fix is to resize the source to roughly the displayed size, or to 2x for retina displays, and to serve different sizes to different viewports via the modern srcset attribute. Resizing a single hero image from 4000 to 1920 pixels typically cuts file size by 60 to 80% and the LCP score follows directly.
• Email attachments. Gmail, Outlook, and Apple Mail all cap attachments at 25 MB per message. A folder of phone photos at full resolution can hit the cap with as few as five or six images. Resizing the long edge to 1920 pixels typically cuts each photo to under 1 MB while staying perfectly viewable on any laptop or phone screen. Twenty photos at 1920 pixels comfortably fit in a single message; the same twenty at full resolution would need three or four sends or a cloud-share link.
• Profile pictures and avatars. Most social platforms want 400x400 to 800x800 pixels for profile photos and display them as a circle. Resizing locally before upload lets you control the square aspect crop (combined with this tool's Image Cropper) and the exact pixel count, rather than letting the platform crop arbitrarily. The retina-display rule of thumb is to upload at twice the display size, so a 200-pixel avatar should be at least a 400x400 source.
• Favicon and app-icon generation. Modern browsers want 16x16 (browser tab) and 32x32 (high-DPI tab), Apple touch icons want 180x180, Windows tile icons want 270x270, and Progressive Web App manifests typically include 192x192 plus 512x512. Resizing one well-designed square source (usually 512x512 PNG with no fine detail) to each of these targets is the canonical workflow for producing crisp icons across every platform.
• Print preparation. A 4x6-inch photo print at 300 DPI needs 1200x1800 pixels of source resolution. A 16x20-inch poster needs 4800x6000. An 8x10-inch print at 240 DPI (newsprint quality) needs 1920x2400. Resizing the source to the correct pixel count for the intended print size means the print lab does not need to auto-resample on your behalf, which avoids unpredictable filter choices and unknown quality settings. Pair the resized pixel count with the right DPI metadata in your print dialog and the result matches what you saw on screen.

Common pitfalls and what they mean

• Upscaling looks blurry, always. A 200-pixel-wide thumbnail enlarged to 1920 pixels will look soft no matter which browser or quality setting was used. Classical interpolation (bicubic, Lanczos, Mitchell) can only smooth between known samples; it cannot invent the missing detail. The information-theory ceiling is set by the Nyquist frequency of the source. For real enlargement that produces sharp output, run the source through a super-resolution tool (Real-ESRGAN, Topaz Gigapixel AI, Adobe Super Resolution in Camera Raw) that hallucinates plausible detail using a neural network trained on millions of similar images.
• Unlocking the aspect ratio stretches the photo. With the lock icon disabled and mismatched width and height, the output is mathematically squished or stretched. The tool defaults to lock-on; unlocking is a deliberate action. If you need to fit a target aspect ratio rather than the source's natural one, the right workflow is to crop first (use the Image Cropper) and then resize the cropped result. That keeps proportions correct and the subject undistorted.
• Pixel art gets smoothed away. This tool's smoothing-on default destroys 8-bit sprites, pixel-grid icons, and any graphic where hard edges between coloured cells are the point. Resampling with any smoothing filter (bilinear, bicubic, Lanczos) blurs those edges into gradients. For pixel art the right answer is nearest-neighbour resize, which preserves every hard edge. Browser-side, set image-rendering: pixelated in CSS on the displayed image. For actual export at a new size, use a desktop tool: ImageMagick's -filter Point, GIMP's "None" interpolation, or specialised editors like Aseprite.
• Re-resizing degrades JPEG and WebP. Each round-trip through the canvas re-encodes JPEG or WebP at quality 0.92. The first pass is visually imperceptible; the third or fourth pass introduces visible artifacts in flat areas and softens fine detail. Always resize from the highest-resolution master you have, not from a copy you exported yesterday. If you need to iterate (try 1920, then 1600, then 1280), go back to the original source each time rather than chaining resizes.
• Print DPI is not the same as pixel dimensions. Many people expect a "DPI" or "resolution" field to control print size. This tool resizes by pixel count only. The DPI metadata tag in a JPEG or PNG is advisory information for printers telling them how many pixels-per-inch to render on paper. Pixel dimensions and DPI are independent: a 1920x1080 image is 1920x1080 pixels at any DPI setting. To control print size you also need to set the right DPI in a print dialog or in a desktop photo tool (Preview's Print pane, Photoshop's Image Size dialog with "Resample Image" turned off).
• Very large images can crash a mobile browser tab. Decoding an image to a canvas needs RAM proportional to its dimensions: a 24-megapixel photo (6000x4000 pixels) needs about 96 MB just for the RGBA source pixel buffer, plus a separate buffer for the target canvas, plus the JPEG or WebP encoder workspace. Mobile devices with 1 to 2 GB of RAM available to the browser may have the tab terminated by the OS before the encode completes. For very large photos, resize on a desktop browser, or downsize in stages (50% first, then 50% again) so each step fits in available memory.

Privacy: images never leave your device

Every cloud-based image resizer (iLoveIMG, ResizeImage.net, ResizePixel, BeFunky, Fotor, Pixlr's resize endpoint, the dozens of "resize image online" services) uploads your file to the operator's servers, runs their resize algorithm, and returns the smaller image as a download. The privacy implications are non-trivial because photos routinely contain identifiable content: faces, addresses visible in backgrounds, screenshots of internal UIs or confidential documents, photos of children, photos taken in private spaces, document scans containing personal information. Most operators publish privacy policies committing to delete uploads within an hour or two and to encrypt in transit, and the bigger ones hold ISO/IEC 27001 certification. They have strong commercial reasons to honour those policies. But "deleted within an hour" is not "never seen." During that hour the image content sits in the operator's infrastructure, accessible to any process or person with appropriate access, and visible in logs and backups according to whatever retention policy applies.

This resizer never uploads anything. The entire pipeline (file pick, image decode, canvas resize, encode, download) runs inside your browser tab using JavaScript and the HTML5 Canvas API. No upload, no network request carrying image data, no log entry. You can verify by opening the browser developer tools to the Network tab before resizing: no requests fire that include image content. The only network traffic is the initial page load and a small image-resizer.js script. Switch the browser to airplane mode after the page has loaded and the resizer keeps working on any local file you select, the strongest empirical proof that nothing is being uploaded. For photos with anything sensitive (faces, locations, internal screenshots, ID documents), the browser-side trade is obviously worth making.

When another tool is the right choice

• Batch automation across hundreds of files. Use sharp in Node.js (the canonical server-side image library, built on libvips), ImageMagick or GraphicsMagick on the command line, or Pillow in Python. These tools handle thousands of files without browser memory limits, expose every resampling kernel as an explicit option, and run from CI jobs, deploy hooks, or cron tasks.
• AI super-resolution for genuine enlargement. For sharp enlargement that actually adds detail, use a neural-network upscaler. Real-ESRGAN (open source, runs locally via ChaiNNer or the CLI), waifu2x (open source, free web demos available), Topaz Gigapixel AI (commercial desktop), or Adobe Super Resolution inside Camera Raw or Lightroom. These models hallucinate plausible detail rather than recovering it; the results look sharp on faces and natural textures because the model has seen many similar images during training.
• Pixel-art resize that preserves hard edges. Use a tool that exposes nearest-neighbour resampling explicitly: ImageMagick's -filter Point, GIMP's interpolation set to "None", or specialised pixel-art editors like Aseprite. This tool always smooths because the Canvas API's imageSmoothingEnabled flag is on; turning it off would degrade every other use case, so the trade-off is in favour of photos rather than sprites.
• Print-grade workflows with DPI control. Adobe Photoshop, Affinity Photo, or Lightroom expose both pixel dimensions and DPI as independent settings, support colour-managed workflows (ICC profile preservation, soft proofing, CMYK output), and remember non-destructive resize history. Browser-based Canvas resize cannot guarantee any of those because Canvas operates in sRGB and may strip embedded colour profiles during re-encoding.

Frequently Asked Questions

Will resizing reduce image quality?

Scaling down preserves quality well. Scaling up (making an image larger than its original) will result in some blurriness since new pixels must be interpolated. For best results, start with the highest resolution source image you have.

What does "lock aspect ratio" do?

When locked, changing the width automatically adjusts the height (and vice versa) to maintain the image's original proportions. Unlock it if you need to stretch or squish the image to exact dimensions.

Is my image uploaded to a server?

No. All resizing happens locally in your browser using the HTML5 Canvas API. Your image never leaves your device.

Can I change the output format?

Yes. You can output the resized image as JPEG, PNG, or WebP regardless of the original format. This is useful for converting formats while resizing.

More frequently asked questions

What's the difference between DPI, PPI, and pixel dimensions?

Pixel dimensions (width by height in pixels) describe what the image actually contains. PPI (pixels per inch) describes how densely those pixels are packed when shown on a screen, a property of the display hardware, not the file. DPI (dots per inch) describes how many printer-output dots will be laid down per inch of paper when the image is printed. The DPI tag embedded in a JPEG or PNG is advisory metadata for printers; it does not change the pixel data. A 1920x1080 image is 1920x1080 pixels at any DPI setting. To shrink a print, either reduce the pixel count (this tool) or increase the DPI metadata before sending to print (a desktop tool's Print dialog or Photoshop's Image Size with "Resample Image" turned off).

Why does my upscaled image look blurry?

Because information theory says it must. Classical resampling (bicubic, Lanczos, Mitchell) can only interpolate smoothly between known source pixels; it cannot invent the detail that was never sampled. The Nyquist-Shannon sampling theorem sets a hard ceiling: frequencies above half the source's pixel-grid rate are mathematically unrecoverable. Enlarging a 200-pixel source to 1920 pixels will always look soft because 90% of the new pixels are interpolated. For sharp enlargement use a super-resolution model (Real-ESRGAN, Topaz Gigapixel, Adobe Super Resolution) that synthesises plausible detail via a neural network trained on millions of similar images.

Should I resize for retina or HiDPI screens?

Yes. Retina iPhone, MacBook, and HiDPI Windows screens render at 2x or 3x the logical CSS pixel density. A hero image that displays at 1200 logical pixels wide on a retina screen actually paints 2400 physical pixels. Serve the 2x source via HTML's srcset attribute (the modern responsive-images standard) and the browser picks the right one for each viewer's device. For a single avatar or hero image without srcset, just resize to 2x the displayed size: the image will be sharp on retina and only slightly oversized on non-retina, which costs a small amount of bandwidth but avoids the much more visible blur of an under-sized image stretched across high-density pixels.

Does this tool work offline?

Yes. The HTML5 Canvas API is part of the browser itself, not a downloaded library, so there is no separate runtime to cache. The page loads in the usual way; once it is open, the resizer runs entirely from browser-builtin code on any local file you select. You can verify by switching to airplane mode after opening the page and resizing a local image. The downloaded result is generated locally and saved by the browser's normal download mechanism, also without any network involvement.

Should I crop before resizing, or after?

Crop first, then resize. Cropping sets the aspect ratio (16:9 for YouTube, 1:1 for Instagram feed, 9:16 for Stories, 1.91:1 for Open Graph) by discarding unwanted edge pixels. Resizing then sets the pixel count for the chosen aspect ratio. Doing the steps in the other order is also possible but wastes work, you would resample more pixels than you need and then throw some away during the crop. For this tool, use the Image Cropper first to set the aspect ratio, then this Image Resizer to set the exact target dimensions. Many platform-specific workflows (YouTube thumbnail at 1280x720, Instagram feed at 1080x1080) combine both steps; doing them in sequence with two purpose-built tools gives cleaner output than trying to do both at once with stretched aspect ratios.

Is there a desktop or command-line equivalent?

Several. For batch automation, sharp in Node.js is the standard server-side library (built on libvips). ImageMagick (magick input.jpg -resize 1920x1080 output.jpg) and GraphicsMagick run from any shell and handle huge files. Pillow in Python (Image.open(p).resize((1920, 1080), Image.LANCZOS)) is the default for data-science workflows. For one-off interactive work like this tool but with explicit per-kernel control and more output formats including AVIF, Squoosh (Google Chrome Labs, entirely client-side) is the recommended browser alternative. Photoshop, Affinity Photo, and Preview on macOS (Tools, Adjust Size) cover the desktop GUI case.

Related Tools