Why a Print-Ready 300DPI Photo Shows Up as 118
You check the DPI of a photo you're about to send to a print shop, one you're sure was shot at 300 DPI, and an oddly specific number like 118 shows up instead. Before you reshoot or start suspecting your editing software, it's worth knowing that this number is very likely the result of an EXIF metadata misinterpretation, not a real quality problem. The number 118 isn't a coincidence, either — it's remarkably close to 300 divided by 2.54 (about 118.1), which is the tell-tale fingerprint of a unit conversion bug.
1. A problem built into the DPI unit itself
DPI (Dots Per Inch) is, as the name says, "the number of dots per inch." But from the perspective of software built in countries that use the metric system, centimeters are a more natural unit for image resolution data than inches. That's why the EXIF standard, separately from the resolution values themselves (XResolution, YResolution), includes a dedicated field called ResolutionUnit (tag 0x0128) that specifies what unit those values are actually in. This field can be one of three values: 1 (no unit), 2 (inches), or 3 (centimeters).
2. The exact arithmetic behind the number 118
Some cameras and image-editing software genuinely store resolution in centimeters and correctly set ResolutionUnit to 3. The problem happens on the reading side — a viewer or DPI checker that ignores the ResolutionUnit field and displays the raw XResolution number as "dots per inch" regardless. Since 1 inch equals 2.54 centimeters, a resolution correctly stored as 300 dots per centimeter would actually be about 300×2.54 ≈ 762 dots per inch if converted properly — but if the reader gets the division direction backwards, it produces 300÷2.54 ≈ 118.1 instead. In other words, 118 is the classic signature of "a value stored in centimeters being read back as if it were in inches."
| ResolutionUnit value | Meaning | Correct handling |
|---|---|---|
| 1 | No unit (pixel aspect ratio info only) | Do not interpret as DPI |
| 2 | Inches | Use the XResolution value directly as DPI |
| 3 | Centimeters | Multiply the XResolution value by 2.54 to convert to DPI |
3. How this tool actually handles it
Checking the actual code of image-dpi-checker.html, it directly parses the TIFF header inside a JPEG's APP1 marker and reads not just XResolution/YResolution (tags 0x011A/0x011B) but also ResolutionUnit (tag 0x0128) — and only multiplies by 2.54 to convert to DPI when the value is 3 (centimeters). The code determines this with const unitToDpi=resUnit===3?2.54:1; and then computes the final DPI as xRes*unitToDpi. In other words, the "118 bug" described in this guide does not apply to this tool itself — it's specifically built to check the unit field explicitly and avoid exactly this kind of misreading. You can upload a file to the Image DPI Checker yourself to see which way its ResolutionUnit was recorded.
4. PNG and WebP have a different problem entirely
Formats without an EXIF structure at all — PNG, WebP, AVIF — are unrelated to the unit-conversion bug described above. These formats mostly carry no resolution metadata whatsoever, so displaying the screen-standard value of 72 or 96 DPI is normal, expected behavior — a default fallback for "no information," not an error. For print files, it's actually more accurate to reverse-calculate DPI by dividing pixel dimensions by the target print size directly — check the pixel dimensions first with the Image Dimension Checker and then divide by the print size in inches.
5. A practical checklist
- If the DPI number looks suspiciously low: check whether it's close to a specific value like 118, 96, or 72. If it's close to a familiar print benchmark divided by 2.54 — 300÷2.54≈118.1, 200÷2.54≈78.7 — that's good grounds to suspect a unit conversion error.
- Check the original file's EXIF directly: the EXIF Viewer shows the raw ResolutionUnit tag value, so you can see exactly how it's recorded in the file itself, not just how one tool interprets it.
- Before handing a file off to a print shop or design program: cross-check with multiple DPI tools — if the values diverge significantly (e.g. 118 vs. 300), a unit-interpretation issue is likely the cause.
Frequently Asked Questions
Q. Does this site's Image DPI Checker have the 118 bug too?
No. Checking the actual code confirms it already reads the ResolutionUnit tag and correctly multiplies by 2.54 to convert to DPI when the value is 3 (centimeters). The bug described in this guide is a general trap that can occur in some other viewers and software that ignore this field — not in this tool.
Q. Why would a camera or software store resolution in centimeters in the first place?
Some devices and software built in regions that default to the metric system (SI) set centimeters instead of inches as their default unit. The EXIF standard itself explicitly permits this and is designed for it to be declared via the ResolutionUnit field, so the value can be perfectly standard-compliant and still cause problems if a reader ignores it.
Q. Does this bug affect PNG files too?
No. PNG doesn't use an EXIF structure, so it's unrelated to the ResolutionUnit conversion issue described in this guide. A PNG showing a low DPI is almost always because it has no resolution metadata at all, falling back to the screen default (72/96) — not a unit conversion error.
Q. If a photo shows 118 DPI, will it actually print at low quality?
If the displayed value is due to a unit conversion error, the actual pixel data itself was never damaged, so checking it again with a correct tool may reveal there's no real print-quality problem. But if 118 is genuinely accurate — a truly low resolution rather than a unit error — printing can come out blurry, so it's always safest to cross-check both the ResolutionUnit value and the pixel dimensions together.