Image Resizer Guide: Pixels, Aspect Ratios, DPI, and Web Optimization

Resizing an image sounds trivial — drag a slider, pick a number. But get it wrong and you end up with blurry upscales, distorted aspect ratios, oversized files hurting Core Web Vitals, or print jobs that come out the wrong size. This guide covers what actually matters when resizing images for the web, for apps, and for print. Use the Image Resizer to follow along.

Pixels vs Percentage Resizing

Most resizers offer two input modes:

Percentage resizing is useful when you need "half the original size" without knowing the exact dimensions. Pixel resizing is the right choice when you have a hard requirement — a profile picture must be 400×400px, a hero image must be 1200px wide.

Aspect Ratio: Lock It or Lose It

An image's aspect ratio is the ratio of width to height. A 1920×1080 image has a 16:9 aspect ratio. A 400×400 image is 1:1 (square).

When you resize to a width and height that don't match the original ratio, the image gets distorted — people look stretched or squashed. Always lock the aspect ratio unless you explicitly need to change proportions (for example, cropping a portrait photo to a landscape thumbnail).

When only one dimension is specified with aspect ratio locked, the other is calculated:

Original: 1200 × 800 px  (3:2 ratio)

Resize to width 600 px (lock ratio):
  height = 600 × (800 / 1200) = 400 px
  Result: 600 × 400 px ✓

Resize to 600 × 600 px (no lock):
  Result: 600 × 600 px — image is stretched ✗

Common aspect ratios

DPI and PPI: Resolution for Print vs Screen

PPI (pixels per inch) describes how many pixels fit in one inch of a digital display. DPI (dots per inch) describes physical ink dots per inch on a printer. They're often used interchangeably but refer to different things.

For screens

Screen resolution is determined by the display, not the image file. A 1920×1080 image displayed on a 24-inch monitor shows at ~92 PPI. The same image on a 13-inch Retina display shows at ~227 PPI — the OS downscales it to the CSS pixel grid. The DPI metadata in the image file has no effect on how an image displays in a browser.

What matters for web performance is the pixel dimensions, not the DPI metadata. A 200×200 image tagged at 300 DPI is the same file size as the same image tagged at 72 DPI.

For print

Print is different. A printer needs enough pixels to produce sharp output at the physical size. The standard for high-quality print is 300 DPI. This means:

Required pixels = physical size (inches) × DPI

Print a 4 × 6 inch photo at 300 DPI:
  width  = 4 × 300 = 1200 px
  height = 6 × 300 = 1800 px
  → You need at least a 1200 × 1800 px source image

Print an A4 page (8.27 × 11.69 in) at 300 DPI:
  width  = 8.27 × 300 ≈ 2481 px
  height = 11.69 × 300 ≈ 3508 px

Why Upscaling Degrades Quality

When you increase an image's dimensions beyond its original size, the resizing algorithm must invent pixel data that doesn't exist. This is called upscaling (or upsampling). The result always looks worse than a native-resolution source.

Different algorithms handle this differently:

Rule of thumb: never upscale more than 2× without an AI upscaler. For web use, always start from the highest-resolution source available and scale down — downscaling always produces better results than upscaling.

Target Sizes for Common Web Use Cases

Retina and High-DPI Displays

High-DPI displays (Retina, 2×, 3× screens) use multiple physical pixels per CSS pixel. An image displayed at 400×400 CSS pixels needs to be 800×800 actual pixels on a 2× screen to look sharp.

In HTML, use srcset to serve the right resolution:

<img
  src="avatar-400.jpg"
  srcset="avatar-400.jpg 1x, avatar-800.jpg 2x"
  width="400"
  height="400"
  alt="Profile"
/>

In Next.js, next/image handles this automatically — provide the largest source you have and it generates multiple sizes:

import Image from 'next/image';

<Image
  src="/avatar.jpg"
  width={400}
  height={400}
  alt="Profile"
  // Next.js generates 1x, 2x, and WebP variants automatically
/>

Resizing vs Compressing: What Reduces File Size More

Both resizing and compression reduce file size, but they work differently:

• Resizing reduces dimensions (fewer pixels = less data to encode). Halving both dimensions reduces the pixel count by 75%, typically cutting file size by 60–80% depending on content.
• Compression keeps dimensions the same but reduces per-pixel detail using lossy (JPEG quality) or lossless (PNG optimization) techniques.

For large web images, resizing to the correct display dimensions first and then compressing is always more effective than compressing a full-resolution image. A 4000×3000 photo compressed aggressively is still larger than the same photo resized to 1200×900 and compressed moderately.

After resizing, run the result through the Image Compressor for the best size-to-quality ratio.

Resizing Programmatically

For server-side or build-time image resizing, sharp is the standard Node.js library — it uses libvips and is significantly faster than alternatives:

npm install sharp

import sharp from 'sharp';

// Resize to exact width, lock aspect ratio
await sharp('input.jpg')
  .resize(800)                   // width only → height auto-calculated
  .toFile('output-800.jpg');

// Resize to exact dimensions (may distort)
await sharp('input.jpg')
  .resize(800, 600)
  .toFile('output-800x600.jpg');

// Resize and fit within a box (no distortion)
await sharp('input.jpg')
  .resize(800, 600, { fit: 'inside' })
  .toFile('output-fit.jpg');

// Resize to cover a box (crop to fill)
await sharp('input.jpg')
  .resize(800, 600, { fit: 'cover', position: 'centre' })
  .toFile('output-cover.jpg');

// Generate responsive sizes
const sizes = [400, 800, 1200, 1920];
for (const width of sizes) {
  await sharp('hero.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`hero-${width}.webp`);
}

Fit modes explained

Quick Checklist Before Resizing

• Do you need exact dimensions or a maximum size? Use pixels for exact targets; use "inside" fit for max-size constraints.
• Is the aspect ratio important? Lock it unless you're explicitly cropping.
• Is this for screen or print? For print, calculate required pixels from physical size × DPI (300 for quality).
• Are you upscaling? If the target is larger than the source, expect quality loss. Consider AI upscaling for significant enlargements.
• Will this be displayed on high-DPI screens? Prepare 2× versions or usenext/image / srcset.
• After resizing, compress. Resize first, then run through the Image Compressor for optimal file size.

Resize images directly in your browser — no upload, no server — with the Image Resizer. For format conversion and compression, see the Image Compressor.