Understanding Image DPI and Resolution for Web

Pixels are real; DPI is metadata

Digital images are grids of pixels—colored dots on a screen. Resolution in web context usually means pixel dimensions: nineteen twenty by ten eighty, eight hundred by six hundred, and so on. DPI, dots per inch, describes how densely those pixels would print on paper. A three-thousand-pixel-wide image set to seventy-two DPI or three hundred DPI contains the same pixel data and looks identical on a monitor.

Changing DPI without resampling does not change file size or on-screen appearance. Software that exports screenshots at seventy-two DPI versus ninety-six DPI is mostly labeling the file, not altering detail. Confusion arises because print workflows use DPI to calculate physical size: three thousand pixels at three hundred DPI maps to ten inches wide on paper.

For FileShrinkr users, focus on pixel width and height first. The compressor scales very wide images to a practical maximum for web delivery. DPI metadata in a JPG exported for email or websites rarely affects how recipients view the file in browsers or mail clients.

What resolution screens actually need

Most laptop screens display content around one thousand to two thousand pixels wide depending on device and scaling. Mobile phones fit readable layouts in three hundred to four hundred CSS pixels width even when the physical display has more pixels through device pixel ratio. Serving a four-thousand-pixel image when the CSS box is six hundred pixels wastes bandwidth because the browser downscales anyway.

Retina or high-DPI displays benefit from roughly two times the CSS pixel dimensions for crispness—an eight hundred pixel wide slot might use a sixteen hundred pixel source. Beyond that multiplier, extra pixels seldom improve perceived sharpness for photographs. Vector SVG icons sidestep the problem entirely for simple graphics.

When preparing images in FileShrinkr, resize in the editor to twice your layout width for photos, or match exact pixel dimensions for thumbnails and cards. Then compress at seventy-five to eighty-five quality. That pairing delivers sharp results without overshooting file size goals.

Print resolution versus web resolution

Print shops often request three hundred DPI at the intended physical dimensions. A five-by-seven inch print at three hundred DPI needs fifteen hundred by twenty-one hundred pixels. Web banners measured in pixels do not need three hundred DPI metadata if pixel dimensions already match the display slot.

If someone asks for a high-resolution file, clarify whether they mean more pixels or different DPI metadata. Photographers exporting for clients should supply sufficient pixels for the largest print size promised—often twenty-four hundred to four thousand pixels on the long edge for casual prints. Web-only deliverables can be much smaller.

FileShrinkr's lossless PDF export preserves original pixels for print handoff. Compressed JPG and WEBP exports target screen and email workflows where smaller files matter more than print margins. Choose the export path that matches the recipient's workflow rather than defaulting to maximum pixels everywhere.

Aspect ratio and layout stability

Resolution pairs with aspect ratio—the proportional relationship between width and height. A twelve hundred by eight hundred image and a twelve hundred by twelve hundred image share width but occupy different vertical space in layout. Cropping to consistent aspect ratios before compression keeps gallery grids tidy and prevents awkward letterboxing in PDF merge output.

Social platforms enforce aspect ratios in previews: square, four-five portrait, sixteen-nine landscape. Exporting at those native ratios avoids platform-side cropping that might cut faces or product edges. FileShrinkr's crop tool helps frame subjects before export.

When merging images to PDF, mixed aspect ratios each receive their own page geometry. Portrait scans and landscape photos in one merge still work, but uniform orientation simplifies printing. Plan aspect ratio at capture or crop stage, not only at compression.

How compression interacts with resolution

Compression algorithms analyze patterns across pixels. Very small images compress quickly but show artifacts sooner because each pixel represents a larger share of the scene. Very large images tolerate lower quality settings because details are abundant, yet file size grows with pixel count even at low quality. The sweet spot is enough pixels for the display context, then tuned lossy compression.

Upsampling a small image to higher resolution before compression does not add real detail—it invents soft interpolation. Start from the best source available, downsample to target dimensions, then compress. If the source is a screenshot, preserve PNG until final export to JPG or WEBP to avoid double JPEG artifacts.

FileShrinkr's pipeline scales wide inputs and applies quality through FFmpeg. Understanding that order helps diagnose results: a soft output might need higher quality, but it might instead need a smaller pixel width so the encoder is not spreading bits across unnecessary area.

Practical export presets for FileShrinkr

Blog inline image: twelve hundred to sixteen hundred pixels wide, WEBP or JPG at eighty percent quality. Product thumbnail: four hundred to six hundred pixels square, WEBP at seventy-five. Email attachment photo: sixteen hundred pixels max, JPG at seventy-five. Full-width hero: nineteen twenty pixels wide max, WEBP at eighty-five unless file size budget is tight.

Scanned document page: fifteen hundred to twenty-four hundred pixels on the long edge, merge to compressed PDF at eighty quality for email or lossless PDF for archival. Social square crop: ten eighty by ten eighty before export, JPG at eighty for platforms that recompress uploads.

Record which preset worked for your audience and reuse it. Resolution and DPI confusion fades once you standardize on pixel targets per channel. FileShrinkr handles scaling and compression; your editorial rules handle how sharp each channel needs to be.