Concise answer
To change image DPI without changing pixel dimensions, update only the image’s density metadata and do not resample. The raster grid remains exactly the same. What changes is the default relationship between those pixels and physical print size. A 3000-pixel-wide image can be 20 inches at 150 PPI or 10 inches at 300 PPI without adding or removing a single pixel.
What “without changing pixels” really means
A metadata-only change preserves:
- pixel width
- pixel height
- total pixel count
- visible raster detail
It changes a stored or interpreted density value where the file format supports it.
That distinction is essential because many “convert to 300 DPI” instructions accidentally mix metadata editing with image enlargement.
If you want the same pixel dimensions after conversion, resampling must stay off.
Example: one file, two metadata values
Start with a 3000 × 2000 image.
At 150 PPI, its default physical size is:
- 3000 ÷ 150 = 20 inches
- 2000 ÷ 150 ≈ 13.33 inches
At 300 PPI:
- 3000 ÷ 300 = 10 inches
- 2000 ÷ 300 ≈ 6.67 inches
The file still contains six million pixels.
Changing the density from 150 to 300 does not make those pixels sharper. It means the same pixels are associated with a smaller physical print size.
Why physical size changes
Pixels, physical size and PPI are connected:
pixels = inches × PPI
If pixels are locked, increasing PPI requires inches to fall.
If inches are locked, increasing PPI requires pixels to rise.
You cannot hold all three values fixed while changing only one of them. This is why image editors offer a resample setting.
Adobe’s current Image Size guidance follows the same model: with resampling disabled, changing resolution changes the physical dimensions while preserving pixel dimensions.
Metadata-only change vs resampling
Metadata only
- pixel dimensions stay fixed
- file may retain nearly the same raster data
- interpreted print dimensions change
- no new image detail is created
Resampling
- pixel dimensions change
- software adds or removes pixels
- file size can change substantially
- image quality can change
- interpolation is involved when enlarging
The correct mode depends on the actual requirement.
When metadata only is the right choice
Use metadata only when:
- the image already has enough pixels for the intended print
- a print portal checks for a specific embedded PPI/DPI value
- a publisher asks for “300 DPI” metadata
- you need to establish an intended physical size without altering the raster
- unnecessary resampling would only enlarge the file
Example: your final print is 6 × 4 inches and the image is 1800 × 1200 pixels. That is already 300 PPI at the target size. If the file metadata says 72, you can update the intended density to 300 without changing the pixels.
When metadata only is not enough
Suppose your image is 1200 × 800 pixels and you need a 12 × 8 inch print at 300 PPI.
The required pixels are:
- 12 × 300 = 3600
- 8 × 300 = 2400
Your source is far smaller.
If you only retag it as 300 PPI, its default physical size becomes 4 × 2.67 inches. It still does not contain the 3600 × 2400 pixels needed for 12 × 8 at 300.
To keep 12 × 8 inches, you need a higher-resolution source or resampling.
How this works in an image editor
In a print-aware editor, the logic is usually:
- open image-size or document-size controls
- disable resampling
- change the resolution field
- observe the physical width and height change
- confirm that pixel dimensions remain constant
- save using a format and export method that preserves the required metadata
The exact menu names differ by software. The principle does not.
How a web converter should handle metadata-only mode
A reliable online tool should:
- read original pixel dimensions
- read existing density metadata if present
- let the user choose the new target
- clearly label “pixel dimensions will not change”
- update the format-appropriate metadata
- read the output back
- show the detected output density
- show the new interpreted print size
- preserve reasonable image quality and unrelated metadata where technically appropriate
For JPEG, the implementation must understand JFIF and EXIF behavior.
For PNG, it should write the appropriate pHYs value.
For WebP, density information may be carried in EXIF, but downstream compatibility needs a warning.
Why the output may still look identical
That is expected.
A metadata-only DPI change should not alter the visible raster. If you compare the images pixel for pixel in a normal screen viewer, they can look exactly the same.
The difference appears when print-aware software maps those pixels to physical dimensions or when a workflow inspects the density metadata.
Why file size might still change slightly
Even when pixel dimensions remain identical, the byte size can change because:
- metadata was added or removed
- JPEG was re-encoded
- compression quality changed
- metadata order changed
- thumbnails or ancillary blocks were rewritten
A metadata-only goal means “do not change the raster dimensions,” not necessarily “the file must have the exact same byte count.”
For JPEG, avoiding unnecessary lossy re-encoding is preferable when the implementation can safely patch metadata without decoding and re-encoding the image.
What about changing 72 to 300 DPI?
This is the classic use case.
If an image is 6000 × 4000 pixels:
At 72 PPI, default physical size is roughly 83.33 × 55.56 inches.
At 300 PPI, it is 20 × 13.33 inches.
The source detail is identical.
If the final job is a 20 × 13.33 print, retagging from 72 to 300 can make the metadata consistent with that intended placement without resampling.
What about PNG?
PNG’s density mechanism is based on pixels per unit, with metres as the absolute unit defined by the pHYs chunk.
A 300 PPI target converts to about 11,811 pixels per metre.
Changing that value can alter the intended physical pixel size while leaving the PNG’s width and height in pixels unchanged.
What about WebP?
WebP can carry EXIF metadata. That means image-resolution fields can be included, but software support varies.
If the destination is a strict print system, test whether it reads WebP density metadata before relying on it. A JPEG or PNG may be more predictable if the service explicitly documents those formats.
Verification after conversion
Never assume the value was preserved through the entire workflow.
After conversion:
- re-open the file in the site’s checker
- confirm pixel width and height
- confirm detected density metadata
- confirm physical-size interpretation
- if the file is going to a print portal, upload a test or inspect its preflight result
A later optimizer or image editor may remove metadata even if the converter wrote it correctly.
Related entities and semantic terms
metadata-only DPI, resampling, PPI, image dimensions, physical print size, EXIF, JFIF, PNG pHYs, WebP EXIF, print metadata.
FAQs
Will a metadata-only DPI change reduce image quality?
It should not alter the raster detail because pixel dimensions stay the same. File encoding can still affect bytes or JPEG compression if the software unnecessarily re-encodes the image.
Why did my print size become smaller after changing 150 PPI to 300 PPI?
Because the same pixels are being packed twice as densely. With pixel dimensions fixed, doubling PPI halves the physical width and height.
Can I meet a publisher’s 300-DPI requirement without resizing?
Yes, if the image already has enough pixels at the required physical size and the publisher mainly needs the correct density metadata. Verify the publisher’s exact specification.
How can I confirm that pixels were not changed?
Compare the original and output pixel width and height. They should be identical in metadata-only mode.
Closing section
Changing DPI without changing pixels is a legitimate operation, but it solves a metadata and physical-size interpretation problem, not a missing-detail problem. The safest tool makes that distinction visible before the user converts anything.
Source and verification notes
Metadata-only behavior checked against current Adobe image-size documentation. JPEG, PNG and WebP storage details are grounded in JFIF, EXIF, W3C PNG and Google WebP specifications.