🔍 Image DPI Changer

What Image DPI Really Means — and Why Changing It Without Resampling Matters

If you've ever exported an image for print and been told it's "too low resolution," you've encountered the DPI problem. Most people's first instinct is to look for a slider that "increases DPI." They find one, drag it up, the file gets bigger, and the printshop still rejects it. That's because they've confused two completely different operations: resampling (adding or removing pixels) and metadata embedding (telling a printer how large to print existing pixels).

DPI — dots per inch — is, at its core, a printing instruction. When you say an image is 300 DPI, you're telling the output device: "For every physical inch of paper, lay down 300 of my pixels." The pixel grid itself doesn't change. A 3000×2000 pixel image at 72 DPI and that same image at 300 DPI contain exactly the same data; the only difference is a handful of bytes in the file header that describes the intended print size. At 72 DPI it would print at about 41.7×27.8 inches. At 300 DPI it would print at 10×6.67 inches — crisp, dense, and suitable for commercial offset printing.

Where DPI Lives in a File

Each image format stores DPI (or its metric equivalent, pixels per centimetre) in a different location:

JPEG uses either a JFIF APP0 segment or EXIF IFD metadata, both stored in the file's header markers. The JFIF APP0 block appears immediately after the SOI (Start of Image) marker 0xFFD8. It contains a density unit byte (0 = no unit, 1 = DPI, 2 = dots per centimetre) followed by two 16-bit unsigned integers for horizontal and vertical density. Changing DPI in JPEG means finding that segment, patching the density fields, and leaving every other byte — all the actual DCT-compressed pixel data — untouched.

PNG stores physical pixel density in a chunk called pHYs. PNG is a chunk-based format: every block has a 4-byte length, a 4-byte type identifier, the data, and a CRC32 checksum. The pHYs chunk holds two 32-bit unsigned integers (pixels per unit in X and Y) and a unit specifier (0 = unknown, 1 = metre). Because PNG works in metres, DPI is converted: 300 DPI × 39.3701 inches/metre ≈ 11,811 pixels/metre. The entire image bitstream is inside IDAT chunks, which are completely unaffected. Injecting or replacing a pHYs chunk requires recalculating its CRC32 using the standard algorithm — the same one used for ZIP files.

WebP carries DPI in EXIF metadata embedded inside an EXIF RIFF sub-chunk. The EXIF block itself follows the TIFF specification: a 6-byte "Exif\0\0" header, a TIFF header declaring byte order (little-endian for most tools), and an Image File Directory (IFD) containing tag entries for XResolution (0x011A), YResolution (0x011B), and ResolutionUnit (0x0128). Each resolution value is a RATIONAL — two 32-bit integers (numerator and denominator). For WebP files that don't already have an extended header, a VP8X chunk must be prepended and its EXIF flag bit set.

The Resampling Trap

When Photoshop resamples an image to a higher DPI, it's doing something fundamentally different: it's inventing new pixels through interpolation. Bicubic or Lanczos algorithms estimate what colour a pixel at an intermediate position would likely be based on its neighbours. This can increase DPI metadata while increasing pixel count, but it cannot recover detail that was never captured. A blurry photo at 72 DPI resampled to 300 DPI is still blurry — just larger and with a matching metadata stamp.

For photography and vector-derived rasterizations, the rule is straightforward: if you already have enough pixels for your target print size at the desired DPI, you only need to change the metadata. A 6000×4000 pixel photograph contains all the information needed to print a 20×13 inch image at 300 DPI. No new pixels required. The only operation needed is patching the density field in the file header.

Print-Ready DPI Standards in Practice

The "300 DPI for print" rule isn't arbitrary. Human visual acuity peaks at roughly 300 cycles per inch at reading distance (~30cm), which correlates to about 600 pixels per inch at the Nyquist sampling rate — but printing processes introduce their own limiting factors (dot gain, halftone screen frequency, paper texture), making 300 DPI the practical gold standard for offset lithography and high-quality inkjet.

The common DPI tiers each serve a distinct purpose:

• 72 DPI: The legacy standard for screen display, inherited from original Macintosh monitors. Entirely suitable for web images, social media, email. Print size at 72 DPI is large, meaning these images are often physically larger on paper than intended.
• 150 DPI: Adequate for newspaper printing (which uses coarser halftone screens, typically 85–100 lpi) and draft proofs where fine detail isn't critical. Also used for large-format displays viewed from several feet away.
• 300 DPI: The standard for magazines, brochures, business cards, and commercial printing. Any printshop PDF template will specify 300 DPI. Colour profiles and ICC colour management assume this density for predictable dot reproduction.
• 600 DPI: Used for fine art reproduction, archival scanning of documents, and specialty printing like fine-line technical drawings. Some high-end laser printers also natively print at 600 DPI.

Why This Tool Processes Locally

Embedding DPI metadata is a byte-level operation performed entirely on the file's header — the image pixel data is never touched, decompressed, or re-encoded. This means it can run completely client-side in a browser with no server round-trip. The tool reads the uploaded image, draws it to a canvas element (which re-encodes it into the selected output format via the browser's own codec), then intercepts the resulting binary buffer before it touches any network. It then injects the correct DPI values directly into the appropriate header structures — JFIF APP0 for JPEG, pHYs for PNG, EXIF IFD for WebP — and offers the result for download.

This approach has a useful side effect: format conversion is free. If you need to deliver a client's PNG asset as a JPEG at 300 DPI, both operations happen in the same pass. The canvas re-encodes to JPEG; the DPI injection patches the resulting JFIF block. Total overhead: milliseconds, entirely within your browser's JavaScript engine.

Common Misconceptions Clarified

One persistent myth is that "screen images are always 72 DPI." This is technically true only in the metadata sense — when a camera or scanner produces an image without specifying a resolution unit, tools default to displaying 72 DPI. But the actual pixel count is determined by the capture device, not by this metadata. A modern smartphone produces images in the 12–50 megapixel range; the DPI metadata typically reads 72 because there was no print instruction embedded at capture time.

Another misconception: that changing DPI "makes the image look better on screen." Screen rendering ignores DPI metadata almost entirely. Browsers and operating systems display images based on CSS pixels or physical device pixels, not embedded DPI values. The DPI number is read by print drivers and professional publishing software. So if you're only distributing images digitally, DPI metadata is irrelevant to quality — it only matters the moment something physical must be produced.

Understanding this distinction — metadata versus pixels — is the foundation of working efficiently with images across both digital and print workflows. Changing DPI without resampling is the correct, lossless operation in nearly every professional context where pixel data is already sufficient.