Image resizer

Change image resolution in the browser, with optional aspect-ratio lock and instant export.

{{ imageResizer.fileName }}

{{ t("imageResizerCropHint") }}

{{ imageResizer.message }}

{{ t("imageResizerHowToTitle") }}

  1. {{ t("imageResizerHowTo1") }}
  2. {{ t("imageResizerHowTo2") }}
  3. {{ t("imageResizerHowTo3") }}
  4. {{ t("imageResizerHowTo4") }}

Overview

The resolution of digital images seems simple but hides decades of engineering decisions that shape how we see the world on screens. The concept of DPI (dots per inch) came from the printing world: a laser printer in the 1980s printed at 300 DPI. Computer screens stayed at 72 or 96 PPI for a long time — the original 1984 Macintosh used 72 PPI, matching the dots per inch of printers of the time and enabling true WYSIWYG. The first IBM CGA screen, in 1981, had a resolution of 320×200 pixels. VGA, in 1987, reached 640×480. Full HD (1920×1080) became standard in the 2000s. In 2010, Apple launched the iPhone 4 with 326 PPI and coined the term Retina display — a screen where the human eye cannot distinguish individual pixels at a normal viewing distance. That forced developers to think in multiple image sizes: the same artwork at different resolutions for different devices.

When you resize an image, the interpolation algorithm determines how new pixels are calculated. The simplest is nearest neighbor: fast, keeps sharp edges in pixel art, but produces jagged edges in photos. Bilinear interpolation considers the 4 neighboring pixels — smoother result, good for moderate downscaling. Bicubic considers the 16 surrounding pixels — even smoother, preferred for photo reductions. The Lanczos algorithm uses a sinc window that preserves high frequencies better than bicubic — common in professional editing tools. For web resizing, the difference is rarely visible to the naked eye, but in print or large enlargements the algorithm matters a great deal.

For web development, resizing images correctly has a direct impact on performance and SEO. A 4000×3000 pixel image displayed in a 200×150 thumbnail forces the browser to download 20 times more data than necessary. HTML5's `srcset` attribute lets you serve images at different sizes per screen resolution, but that starts with having the files at the right dimensions. Standard sizes that come up constantly in daily work: Open Graph (1200×630), Twitter Card (1200×628), favicon (16×16, 32×32, 180×180), YouTube thumbnail (1280×720), and PWA icons (192×192, 512×512). This tool resizes PNG, JPEG, and WebP on the browser canvas, without upload, with optional aspect-ratio lock to avoid distortion.

Technical deep dive

Common questions summarized

  • Does quality always drop when resizing?: When downsizing, quality loss is usually small and can even look better for web use. When upsizing, perceived loss is higher.
  • What is this tool for?: It runs fully in your browser: useful to validate, format, or convert data in everyday development.
  • Are my inputs sent to a server?: Processing happens locally with JavaScript. We do not store what you paste into the text areas.
  • Can I use this for real production data?: Use at your own risk. For secrets (passwords, tokens), prefer controlled environments and your company policies. And always review the generated contents. Never trust blindly things you see on the internet.

Sample payload to try

  • See also the larger "Code Snippets" sample; paste this excerpt to try locally: Example — 1920x1080 → 1280x720 (mesma proporção 16:9)

Code Snippets

Code example
1920x1080 → 1280x720 (mesma proporção 16:9)

Example

1920x1080 → 1280x720 (mesma proporção 16:9)

FAQ

Does quality always drop when resizing?

When downsizing, quality loss is usually small and can even look better for web use. When upsizing, perceived loss is higher.

What is this tool for?

It runs fully in your browser: useful to validate, format, or convert data in everyday development.

Are my inputs sent to a server?

Processing happens locally with JavaScript. We do not store what you paste into the text areas.

Can I use this for real production data?

Use at your own risk. For secrets (passwords, tokens), prefer controlled environments and your company policies. And always review the generated contents. Never trust blindly things you see on the internet.