Image Dimensions Checker

The Image Dimensions Checker reports the exact pixel width and height of any image you drop into the page, along with the aspect ratio and the megapixel count that follow from those two numbers. Because the whole read happens in your browser through the Canvas API, the file itself never leaves your device - there is no upload, no queue, and no server step between choosing a file and reading its true dimensions.

The value of a dimension check is that it reveals the real, uncompromised size of a file rather than the size it appears to be when displayed. HTML and CSS can scale a photo down until it occupies a tiny box, and background images may render at whatever the container dictates. The checker reads the intrinsic bitmap size - the native pixel grid stored in the file - which is the number that actually drives print, crop and publishing decisions.

Beyond the raw pair of numbers, the readout derives two pieces of context. The aspect ratio expresses width and height as a simplified pair such as 16:9 or 4:3, telling you which layout shapes the image already fits. The megapixel figure - width times height divided by one million - condenses the total amount of image data into a single number, so files of very different sizes can be compared without opening each one.

Supported inputs are JPG, PNG, WebP, AVIF, GIF, BMP and SVG. Raster formats report their true pixel grids; SVG files, being vector descriptions rather than pixel arrays, report the logical size declared in their viewBox or width and height attributes. That distinction matters more than it sounds: a crisp SVG logo can read as a modest number and still render sharply at any size, which is exactly the behaviour of a vector rather than a bitmap.

Typical reasons to run a check include verifying a submission meets a publisher's minimum size, confirming that a batch of exported thumbnails share one width, and catching the classic situation of a huge camera file that a platform will only accept after being resized down. Because the check is instant and fully local, it becomes a natural bookend: run it before publishing to confirm a file qualifies, and run it again after a resize to confirm the output landed where intended.

Two limits are worth knowing before you start. Files above roughly 25 MB may exceed comfortable browser memory and fail to decode, so very large source exports should be compressed or cropped first. And this checker reports pixels, not print density - if your question is DPI or PPI for print, the Image Resolution Checker is the closer fit. Throughout, the original file is left untouched: reading dimensions creates nothing, writes nothing and deletes nothing except the copy in temporary memory that the browser already owns.

Every raster image is a grid of color samples, and that grid has a fixed width and height in pixels no matter how the file is displayed. The tool reads this intrinsic grid by drawing the image onto an off-screen canvas and asking for the canvas width and height back - the same numbers a layout engine consults when it needs to reason about the image on its own terms, rather than through the lens of a styled container.

Display scaling changes how large an image looks, never how many pixels it holds. A 4000 by 3000 photo shown at 400 pixels wide is still a 4000 by 3000 pixel file. Browser zoom, window resizing and high-density monitors all shift the rendered size and the number of physical screen pixels used, but the file's intrinsic dimensions stay fixed, which is precisely the value the checker reports.

• CSS and HTML scaling only affect the rendered box, never the stored pixel grid.
• Device-pixel-ratio values such as 2x and 3x change how many screen pixels each CSS pixel covers, not the image's own dimensions.
• Crop and compress tools change the intrinsic grid; display tools only change its presentation.
• A thumbnail that renders sharply can still be a huge file underneath - the readout shows the truth.

A dimension check is only useful when you have a target in mind, and different publishing contexts expect different pixel footprints. Keeping a short reference in mind turns the raw readout into an instant yes-or-no verdict: does this file qualify for where I am sending it?

The table below lists the size bands most destinations work with today. They are frequent real-world starting points drawn from typical web and print practice - your project's own documented requirements always take precedence over any general list.

Once width and height are known, the megapixel count summarizes the total pixel inventory. It converts a two-number pair into one comparable figure - 12 megapixels versus 24 megapixels is a quick way to gauge image data without multiplying anything by hand. The summary is coarse, though: two files at the same count can differ widely in quality, because sensors, exposure and lenses do the actual heavy lifting.

Megapixels also describe how much room you have to crop or enlarge. A 45 MP file can survive a deep crop that a 2 MP file cannot, simply because it starts with more pixels to give away. The table below groups realistic output targets by the pixel budget they tend to need.

Aspect ratio reduces width and height to two integers divided by their greatest common divisor, so 3840 by 2160 becomes 16:9 and 4032 by 3024 becomes 4:3. Hundreds of pixel pairs collapse into a small set of familiar shapes, which makes the ratio the fastest way to know whether an image will fit a destination frame without cropping surprises.

The ratio says nothing about quality, file size, or how many pixels exist. A 1280 x 720 and a 3840 x 2160 file are both 16:9; they differ enormously in resolution yet share a shape. When a destination rejects an image for the wrong proportions, it is the ratio - not the megapixel count - that is out of agreement.

• 16:9 suits widescreen heroes, video frames and TV-safe crops.
• 4:3 and 3:2 reflect typical camera sensors and classic print proportions.
• 9:16 is the vertical counterpart for stories, shorts and reels.
• 1:1 squares feed grids, avatars and product tiles.

SVG is not a grid of pixels but a set of drawing instructions - shapes, paths and fills rendered on demand. Because there is no fixed bitmap, the checker reports the logical width and height the author declared, usually through the viewBox attribute or width and height properties. That number is a canvas suggestion, not a pixel count.

This is why an SVG can report a modest size and still look perfectly crisp blown up to a billboard. It is also why comparing an SVG to a raster JPG on numbers alone is misleading; the two formats measure different things. When a project demands a concrete pixel grid, export the SVG to a raster format and check the result instead.

A dimension readout is diagnostic, not decorative. If the file falls short of a minimum requirement - a print shop asking for 2400 px on the long edge, a newsroom requiring 1600 px width - the gap is now a number you can act on. If it exceeds every target, you have room to downscale and shrink file size without losing anything that matters.

The same number tells you when not to act. An image that already matches its destination needs no resize, and resizing would only degrade or bloat it. The check also exposes assets that are effectively undersized for their stated job, such as a 640 px wide file labeled as a hero image.

• Compare against the documented minimum, not a guess.
• Resize, then re-check, to confirm the output landed correctly.
• Batch-check a folder to catch a single off-size export.
• Pair the readout with a format check when the extension is in doubt.