Stephen J.If an exported image suddenly reports 72 DPI, first compare its pixel dimensions with the original. If the width and height in pixels are unchanged, the image has not automatically lost raster detail just because a program now displays 72. The export may have rewritten, stripped or stopped reading the physical-density metadata.
The correct diagnosis starts with pixels, metadata source and intended print size.
Step 1: compare pixel dimensions
Imagine the original is:
3600 × 2400 pixels at a displayed 300 PPI.
After export, another app says:
3600 × 2400 pixels at 72 PPI.
If those dimensions really are unchanged, the file still has 8.64 million pixels.
The nominal physical-size interpretation changes:
At 300 PPI: 12 × 8 inches.
At 72 PPI: 50 × 33.33 inches.
But no pixel sample disappeared merely because the metadata changed.
Step 2: check whether the exporter resampled
The situation is different if the export becomes:
864 × 576 pixels at 72 PPI.
Now the raster itself is smaller.
The export may have:
- applied a web preset
- set a maximum width
- changed dimensions through scaling
- generated a thumbnail or derivative
- used an export option that resampled the image
That is a real loss of pixel dimensions.
Do not diagnose the problem from the DPI field alone.
Why 72 appears so often
72 PPI has historical significance in desktop publishing and screen-oriented workflows. Some software still uses it as a default physical-resolution assumption.
But a 72-PPI display value can mean several different things:
- an actual embedded density tag
- a value written by the exporter
- a fallback used when metadata is missing
- a value shown by an application that ignores another metadata field
A proper checker should attempt to identify which applies.
JPEG-specific causes
JPEG can carry density information in JFIF and EXIF structures.
An exporter might:
- keep EXIF but rewrite JFIF
- remove EXIF for privacy or size
- create a new JFIF density
- normalize conflicting values
- discard both and let the receiving application use a fallback
This explains why two programs can show different physical resolution for the same pixel raster.
PNG-specific causes
PNG’s optional pHYs chunk stores physical density as pixels per unit, normally pixels per meter.
If an exporter omits that optional chunk, the PNG can still contain exactly the same visible pixels.
Another application may then use its own default physical-size assumption.
WebP-specific causes
WebP can carry optional EXIF metadata, but support for reading and preserving it varies across tools.
A WebP exported for web delivery can therefore lose a density tag even while maintaining the image dimensions.
Does 72 PPI matter for a website?
Usually not in the way print users expect.
A browser’s rendered size is controlled primarily by HTML/CSS layout, intrinsic pixel dimensions, responsive image selection and device pixel density.
A 1200 × 800 image remains 1200 × 800 source pixels whether its EXIF says 72 or 300 PPI.
If it appears soft on a high-density screen, investigate whether the delivered raster is large enough for the rendered CSS size.
Does 72 PPI matter for printing?
It can affect default physical placement in software that honors the metadata.
But for a defined print size, calculate effective PPI:
A 3600-pixel-wide image placed 12 inches wide:
3600 ÷ 12 = 300 PPI
Even if its metadata says 72, that placement uses 300 image pixels per print inch.
A print workflow may still require a particular embedded density value. If so, change or write that metadata deliberately without assuming you need to resample.
A troubleshooting checklist
When the number changes after export, record:
- original pixel width and height
- exported pixel width and height
- original file format
- exported file format
- original density metadata
- exported density metadata
- whether the app used a resize/export preset
- required final print dimensions
Then classify the issue.
Pixels unchanged, metadata changed
Usually a metadata or application-interpretation issue.
Pixels changed, metadata unchanged
A real resize occurred even though the density tag may look familiar.
Both changed
The exporter probably performed a resampling operation and wrote a new physical resolution.
No metadata detected
Calculate print size from actual pixels at your chosen PPI.
How to restore the intended density safely
If you need a specific tag:
- keep a backup of the original
- enter the intended PPI
- disable resampling when you want to preserve pixels
- export in a format and workflow that supports the required metadata
- inspect the resulting file again
For this website, the Check Image DPI tool and converter should work together: check, convert, then check the downloaded result.
What not to do
Do not immediately upscale an image simply because it shows 72 PPI.
Do not assume a 300-PPI label proves quality.
Do not judge print suitability without knowing physical output dimensions.
Do not trust one application’s display when a metadata conflict is possible.
Related entities and semantic terms
72 DPI, 72 PPI, export, metadata, EXIF, JFIF, PNG pHYs, WebP EXIF, pixel dimensions, effective PPI, resampling.
FAQs
Why can “Save for Web” style workflows remove physical-resolution metadata?
Web-oriented exports often prioritize pixel dimensions and file size. Optional metadata can be removed because browser layout generally does not need a physical print-density tag.
If an export stays 6000 × 4000 pixels, can it still be suitable for a large print even if it says 72 DPI?
Yes. Calculate effective PPI from the intended physical print dimensions. The 6000 × 4000 raster has not become small merely because a metadata field changed.
Why might two apps disagree even when both show a DPI value?
They may be reading different metadata structures, applying different fallback assumptions or interpreting units differently.
Should I recheck the file after changing its DPI metadata?
Yes. Verification confirms that the output format actually contains the intended density information and that pixel dimensions were preserved when required.
Closing section
Treat 72 DPI as a clue, not a verdict. Compare the pixel dimensions first, identify whether metadata was changed or lost, and calculate effective PPI for the final print. That sequence separates a harmless metadata change from a genuine resize.
Source and verification notes
JPEG, PNG and WebP metadata behavior was checked against JFIF, CIPA EXIF, W3C PNG and Google WebP container specifications. The article does not claim that all applications use the same fallback behavior.