Choose a format, then judge the image
PNG is lossless and suits crisp raster graphics. Ordinary JPEG is lossy, suits photographs, and has no alpha transparency. WebP supports lossy or lossless compression, transparency, and animation.
Example: compare JPEG and WebP for a product photo; consider PNG or lossless WebP for small text.
Pitfall: smaller files are not automatically worse. Lossless encoding settings alone can change byte size. Compare exports at their intended display size, checking edges and fine detail. A quality slider is not a universal quality score.
References: Mozilla: image file types · Google: WebP format · Google: WebP encoder options
Pixels and resolution tags are different
Pixel dimensions describe width × height. Resolution metadata, often labelled DPI or PPI, relates those pixels to a physical size; it does not create detail.
Example: 1600 × 1200 pixels corresponds to 8 × 6 inches at 200 PPI, or 4 × 3 inches at 400 PPI. Changing only the tag leaves the pixel grid unchanged.
Pitfall: a 300 PPI tag does not prove sharpness. Resampling changes pixel dimensions; changing only resolution metadata does not. For screen assets, follow the destination’s pixel-size requirement.
References: Adobe: image size and resampling
Check for actual transparent pixels
Alpha describes opacity. In an 8-bit alpha channel, 0 is fully transparent, 255 is opaque, and values between are partly transparent. A file can include alpha information while every pixel remains opaque.
Example: preview a white logo over both dark and light backgrounds. A white preview alone cannot distinguish white pixels from a transparent area shown over white.
Pitfall: a checkerboard can be painted into the image. Only decoded pixel alpha establishes actual transparency. If the pixel scan is skipped, transparency remains unverified; a format’s support for alpha is not a pass.
References: W3C: PNG alpha representation
Why a JPEG’s dimensions can look reversed
A JPEG can store pixels in one orientation and use EXIF metadata to tell viewers how to rotate or mirror them. A viewer that follows that instruction may show different width and height from the stored pixel grid.
Example: a stored 4000 × 3000 image rotated a quarter turn is displayed as 3000 × 4000.
Pitfall: removing orientation metadata alone can change the appearance. If an export needs normalized pixels, apply the orientation and reset or remove the tag together, then reopen the result in the destination app.
References: W3C: image orientation
Three export checks, worked through
These are hypothetical files, not test results. Start with the destination’s requirements, then separate what a file check establishes from what still needs a visual review.
1. A logo that must have a clear background
Requirement: exactly 512 × 512 pixels, with transparency. Suppose a PNG has those dimensions and includes alpha, but the full pixel scan finds every pixel opaque. The size passes; transparency fails. Renaming it or choosing PNG again will not clear its background. Return to the source artwork and export without the background layer. If transparent pixels are found, still inspect the edges over light and dark backgrounds. One transparent pixel does not prove the whole background was removed.
2. A product photo below a byte limit
Requirement: at least 1600 × 1200 pixels and no more than 500 KiB. Suppose a JPEG is 1800 × 1350 pixels and 320 KiB. It passes those two requirements, but they do not establish sharpness, correct color, or a good crop. A 300 PPI tag would not change that conclusion. Compare the export with the source at the intended viewing size, particularly around fine texture and high-contrast edges. Keep the source so you can make another export.
3. A portrait whose stored grid is landscape
Requirement: a portrait image at least 3000 × 4000 pixels. Suppose a JPEG stores 4000 × 3000 pixels and requests a quarter-turn through EXIF. A browser that honors the tag displays 3000 × 4000. Use the oriented dimensions for that display requirement, while keeping the stored pair visible. Reopen the file in its destination app: the inspector cannot prove that another app applies the same orientation. If the workflow needs normalized pixels, export a correctly oriented copy and check it again.
A skipped pixel scan is an unknown result, not a transparency pass. Animated files receive metadata-only checks here; their frames are not individually inspected.
How the checks work, and where they stop
The inspector identifies a file by its signature and parses bounded PNG, JPEG or WebP structures. PNG chunk checksums are checked. Baseline, extended-sequential and progressive JPEG frame headers are supported. WebP canvas and still-frame dimensions are compared. Detected structural errors and unsupported formats receive an error rather than a guessed size. This is a practical inspector, not a standards conformance validator.
Eligible still images are decoded with the browser’s createImageBitmap API, using its orientation and color handling. A canvas scan counts zero-alpha, partial-alpha and opaque pixels in that decoded image. Preview images are reduced for display; the transparency count uses the full decoded image. Tiny 16-bit alpha differences can be rounded by the browser’s 8-bit canvas output. Browser support and color rendering may differ between devices.
Animated PNG and WebP receive container metadata only: no frame preview, transparency verdict or displayed-dimension pass. Still images above 16 million pixels or 16,384 pixels on either side are not decoded. These limits control memory use and are not export recommendations. A decode timeout prevents further scans in that batch; clear the files before trying again. HEIC, AVIF, SVG, GIF, TIFF and PDF are outside this tool’s scope.
EXIF orientation and common metadata markers are identified without listing the contents. A “no markers detected” result does not certify that private metadata is absent. No color-profile validation, compression-quality estimate, file repair, conversion, malware scan or metadata stripping is performed.