Resize vs Crop: Getting Image Dimensions Right for Web and Social

You upload a 6000×4000 photo to an e-commerce listing that displays it at 400×300, and the store's pipeline rescales and recompresses it as a side effect of publishing. The photo survives, but the PNG screenshot you also shipped now looks smeared: the script scaled it to an odd dimension, ran it through a second JPEG compression, and turned your crisp interface text into soft edges. Nothing about your source file was wrong — the damage is a resize and a re-save happening on a file that had already been encoded once, with no idea what the final size was supposed to be. This guide is about controlling that process: what resize and crop really do, why DPI has almost nothing to do with web pixels, which dimensions the social platforms actually expect, and how Convrs' browser tools do the same job without a single file leaving your device.

Resize and crop: two operations, one image

The two commands look similar because both change the image dimensions, but they work differently, and you almost always want to choose one deliberately.

• Resize scales the whole image: every pixel is squashed or stretched into a new width and height, and the aspect ratio is preserved unless you force a mismatched size. Use it to fit a placement's maximum dimension or to shrink a file before upload.
• Crop keeps one rectangular region and discards everything outside it. The image gets smaller because you removed content, and in almost every case the aspect ratio changes. Use it to reframe, cut away a cluttered edge, or match a platform ratio (16:9, 1:1, 4:5, 9:16).

The practical pipeline is usually crop first, resize second: crop to the aspect ratio the placement demands, then resize the result to the pixel size. Doing it the other way around means resizing a frame that still carries unwanted content, or cropping a file that has already been interpolated — a small but real quality loss.

The damage you cannot undo: recompression

JPEG and WebP are lossy. Every save re-quantizes the pixels, discarding what the encoder considers invisible detail. Recompression compounds this: a JPEG resized down and saved again is a second generation, and fine edges — text, logos, UI screenshots — develop halos, mosquito noise and softness. By the third or fourth generation the degradation is obvious even at thumbnail size. PNG is lossless per save, but a PNG screenshot scaled to a non-integer dimension and then re-encoded is still interpolated: diagonal lines get stair-stepped and text goes fuzzy.

The rule that prevents all of this is keep the master. Save the original capture, resize exactly once, and export from it. If you no longer have the original — or you do have it, but it is the recompressed monster from step three — treat your best copy as the new master and stop editing it.

Pixels, not DPI: what '300 DPI' actually means

A digital image is a grid of pixels with exactly two properties: width and height. That is all the web reads. DPI (dots per inch) and PPI (pixels per inch) describe how densely a printer lays those pixels onto paper — print-only concepts stored as metadata. A 1200×1200 image is 1200 pixels on every screen, laptop or phone, whatever its DPI tag says.

When a client asks for a '300 DPI image', they are almost always asking for print quality. At 300 PPI, a 5×7 inch print needs about 1500×2100 pixels; a web banner at that size is overkill. Raising the DPI number in an editor does not add pixels — it rewrites metadata, and in some tools it re-encodes the file for nothing. For web and social the only question is the pixel dimensions.

Aspect ratios and pre-sizing for social

Platforms crop and scale your uploads to fit their own placements, and what they key off is your aspect ratio (width:height). Get the ratio right and you keep control of the frame; get it wrong and the platform's crop decides what your audience sees. The ratios you will meet in practice:

• 16:9 for landscape video and most shared link cards (Facebook/LinkedIn).
• 1:1 for Instagram feed squares and profile grids.
• 4:5 for portrait feed posts — the tallest ratio the Instagram feed shows without cropping.
• 9:16 for Stories, Reels, Shorts and TikTok.

The placements worth memorizing:

Pre-sizing rule: build the largest placement you actually need and crop down from it. If both a feed post (1:1) and a story (9:16) matter, produce the square at 1080×1080 and then prepare the vertical from the same master — do not carve a 9:16 frame out of an already-small square. Platforms recompress what you upload; hand them the exact ratio and a comfortably large file and they compress once instead of twice.

Resizing in the browser with canvas

When you resize in code — here, or in an upload widget — the browser gives you canvas, and two flags control the quality. Sharp downscaling of a photo needs smoothing enabled, and imageSmoothingQuality: 'high' switches the browser into a more expensive but visibly better filter. EXIF rotation is worth handling too: phones record photos upright but mark them with a rotation tag, and naive drawImage calls ignore that tag — your photo comes back sideways.

async function resizeToMax(file, maxDim, quality = 0.82) {
  // Decodes the image and respects the camera's EXIF rotation tag
  const bitmap = await createImageBitmap(file, {
    imageOrientation: "from-image",
  });

  const scale = Math.min(1, maxDim / Math.max(bitmap.width, bitmap.height));
  const w = Math.max(1, Math.round(bitmap.width * scale));
  const h = Math.max(1, Math.round(bitmap.height * scale));

  const canvas = document.createElement("canvas");
  canvas.width = w;
  canvas.height = h;
  const ctx = canvas.getContext("2d");
  ctx.imageSmoothingEnabled = true;
  ctx.imageSmoothingQuality = "high";
  ctx.drawImage(bitmap, 0, 0, w, h);

  // To crop instead, draw only the source rectangle you want to keep:
  // ctx.drawImage(bitmap, sx, sy, sw, sh, 0, 0, w, h);

  const blob = await new Promise((resolve) =>
    canvas.toBlob(resolve, "image/webp", quality) // or "image/jpeg"
  );
  bitmap.close(); // release the decoded bitmap's memory
  return blob;
}

The scale is capped at 1 on purpose: the Math.min(1, ...) clamp means this function can never upscale. The output is only ever the same size or smaller — exactly the rule for web images.

When to resize in a tool and when to let CSS handle it

CSS resizes rendering, not bytes. max-width: 100%, object-fit: cover (a CSS crop) and responsive srcset with sizes adapt the displayed image to any viewport — that is correct and cheap. But the browser still downloads the original file. Shipping a 6000×4000 JPEG so CSS can shrink it to 400px wastes megabytes on every page view and keeps the image on the network far longer than anyone notices.

The web-friendly sequence: resize the file itself to the largest size any placement needs — commonly the 2× rule for retina, so 1920 or 2400 wide if it can ever be viewed full-screen — then let CSS scale it down for smaller breakpoints, and point srcset at a couple of explicit sizes for slow devices. Image files are static: make them right once instead of charging a recompression tax to every visitor.

Round numbers, powers of two, and the no-upscale rule

Three habits keep exports predictable. First, export to round dimensions: 1200 wide, not 1193. Odd numbers come from chained scaling math and invite visible interpolation artifacts. Second, if you resize by a fixed factor, prefer clean step sizes — 0.5×, 0.25× — because some pipelines (tiling, mipmaps, texture atlases, certain thumbnailing services) resample best on powers of two: a 2048-pixel source downscaled to 1024 averages 2×2 blocks cleanly, while 1000 introduces fractional sampling.

Third, the rule that fixes more blurry images than any filter: never upscale a web image beyond its native resolution. Upscaling invents pixels. A 400px-wide image stretched to 1200px is still 400px of real detail — the interpolation guesses the rest, and no sharpening filter adds information that was never captured. If a placement needs 1200px and your source is 400px, re-shoot or re-render; do not try to 'improve' it in the editor.

Filters and watermarks: finishing steps, in the right order

Filters and watermarks belong at the very end, after resize and crop have locked the final frame. Watermark first, then crop, and you cut your own logo out of the picture; watermark before resizing and the text may shrink into illegibility, or the mark scales relative to a frame that is not the one delivered.

A sane order: (1) apply the look — grayscale, sepia, brightness/contrast, saturation, blur — to the source; (2) crop to the target ratio; (3) resize to the target pixels; (4) add the watermark with size and opacity relative to the final image; (5) export once. Text watermarks usually survive small sizes better than image watermarks; 4–6% of the shorter side at 30–50% opacity in a corner is the common, unobtrusive default. Exporting once, after every edit, is what holds the quality tax to a single generation loss.

The image tools in Convrs

Convrs puts the whole pipeline in the browser, and files never leave your device: Image Resizer resizes by pixels or by percentage with quality control, Image Cropper cuts to aspect-ratio presets (16:9, 1:1, 4:5, 9:16) or a custom box, Image Filters applies grayscale, sepia, brightness/contrast/saturation and blur, Watermark Adder overlays a text or image watermark with position, size and opacity, and Image Compressor reduces file size for uploads. Crop with the ratio locked, resize to the platform pixels, sharpen the look, watermark once, compress for the road — the master and every derived file stay on your machine, and only the finished export ever moves.