Image Dimensions Checker

How the Tool Reads Width and Height From Bytes

Every read starts at byte zero. A PNG opens with 89 50 4E 47 0D 0A 1A 0A, a JPEG with FF D8, a GIF with the ASCII text GIF87a or GIF89a, a WebP with RIFF at offset 0 and WEBP at offset 8, a BMP with BM, and the ISO container formats with an ftyp box at offset 4 whose brand decides whether the file is reported as AVIF or HEIC. Matching a signature picks the reader, and when nothing matches the file is reported as Unknown instead of guessed from the extension. The PNG reader pulls width and height from IHDR at offsets 16 and 20, reads bit depth and color type out of the same 13-byte header, then steps through the chunk list for pHYs density, tRNS transparency, and an acTL frame count that marks the file as APNG. The JPEG reader walks markers until it hits a start-of-frame marker in the 0xC0 to 0xCF range (0xC4, 0xC8, and 0xCC excluded), where six bytes hold precision, height, width, and component count. Before that it can pick up the APP0 JFIF density and the APP1 Exif block, whose IFD entry with tag 0x0112 yields the orientation value shown in the results. The GIF reader takes width and height from the logical screen descriptor at offsets 6 and 8 in little-endian order, then counts image descriptor blocks to report how many frames the animation holds.

The remaining formats each have their own shape to walk. WebP is a RIFF container of chunks: VP8X carries the canvas size in three-byte little-endian fields plus alpha and animation flags, VP8 lossy stores width and height as 14-bit fields behind the 9D 01 2A frame tag, and VP8L packs them into 14-bit bitfields after the 0x2F signature. BMP reads width, height, and bits per pixel from the DIB header at offset 14, covering both the 40 byte BITMAPINFOHEADER and the 12 byte BITMAPCOREHEADER, and it notices top-down row storage. AVIF and HEIC share the ISO base media container, so a scan for ispe boxes returns the largest pixel size, which is what multi-image files need. ICO reads the directory of 16 byte entries and reports the largest one, because a favicon file usually packs 16, 32, 48, and 256 pixel versions together. TIFF resolves the first IFD and reads tags 256 and 257 for the pixel size plus tag 274 for orientation, honoring byte order from the II or MM header. SVG is the only text format here: the reader decodes the first 4096 bytes, looks for width and height attributes, and falls back to the viewBox rectangle when those attributes are missing.

Dimensions without decoding

A header walk touches a few hundred bytes instead of a full decompress. No pixel buffer is allocated, no canvas or ImageBitmap is created, and the built-in image decoder never runs, so a file that would take a moment to render paints its numbers immediately. It also makes a truncated or corrupt file safe to inspect, since every reader stops at the end of the buffer and reports whatever it found instead of throwing. And because nothing is drawn, a confidential photo stays off the screen while you read it.

Pixels are only half the story

A 320 CSS pixel slot on a 2x phone draws from a 640 pixel source, so shipping 320 pixels leaves the picture soft on the device most of your visits come from. The width and height attributes on the image tag tell the browser the ratio before the bytes arrive, which is what holds Cumulative Layout Shift at zero while the picture loads. Matching srcset and sizes values let the browser pick a 640 or a 1280 candidate instead of taking the largest one by default. When the picture sets Largest Contentful Paint, add fetchpriority=high so its download starts ahead of lower-value resources.

Before and after: a hero image checked before shipping

Before (dropped in blind)

hero.jpg     4032 × 3024 px    11.4 MB
slot CSS     640 px wide
attributes   none on the img tag
served       full 4032 px candidate
LCP          3.8 s on Slow 4G
layout       0.21 CLS, text jumps

After (read first, sized for 2x)

hero.webp    1280 × 720 px     91 KB
slot CSS     640 px wide
attributes   width=1280 height=720
served       1280 px, exactly 2x of 640
LCP          1.2 s on Slow 4G
layout       0.00 CLS, box reserved

Use Cases

Frontend	Performance	Design handoff
Fill in width and height attributes for a picture added to a card component	Find the oversized hero that is holding back Largest Contentful Paint	Confirm a delivered asset matches the size promised in the ticket
Check whether an SVG logo carries a viewBox so it scales inside CSS	Catch a 4032 × 3024 camera JPEG served into a 640 pixel slot	Verify an exported icon set uses one consistent pixel size
Read PNG bit depth and color type before wiring up a sprite sheet	Spot animated GIFs that should ship as video or animated WebP	See the EXIF orientation flag a handoff file arrived with

Common Mistakes

Serving a 4032 by 3024 camera JPEG in a 640 pixel card slot. The browser pulls twelve megapixels to paint a box that is 640 wide, and the extra bytes hold back the largest element on the page.
Leaving the width and height attributes off the image tag. With no ratio known up front, the browser reserves an empty box and the text below jumps when the pixels land, which shows up as layout shift in the report.
Trusting the file extension. A file named .png can hold JPEG bytes and a .webp can be a re-wrapped JPEG, so the checker reports what the magic bytes say instead of what the name claims.
Resizing a JPEG without looking at the EXIF orientation tag. When it reads 6 or 8 the pixels are stored sideways, and a resizer that ignores the flag saves the photo rotated for everyone who opens it after you.
Measuring only CSS pixels. A 320 pixel slot on a 2x phone draws from 640 physical pixels, and a source with just 320 looks soft on the device that most of your visits come from.
Re-encoding an animated GIF as a still image. Grabbing a single frame loses the animation and barely moves the file size, while the multi-frame original inflates every thumbnail it appears in. Convert the animation to short video or animated WebP instead.

Best Practices

Read the dimensions before writing markup, then put the real width and height into the image attributes or a CSS aspect-ratio rule so the box exists before the bytes arrive.
Size the export for the pixel ratio you support. A 640 pixel file fills a 320 CSS pixel slot at 2x, and 2x covers nearly every phone in the field.
Ship two or three srcset candidates with a sizes value that matches the actual layout, so a 390 pixel phone never downloads the 1600 pixel version.
Give the Largest Contentful Paint image fetchpriority=high and preload that one file only. Preloading pictures declared in CSS spends the early bandwidth the hero needs.
Apply EXIF orientation once at export, then strip the metadata block. The photo stops rotating in tools that ignore the tag, and the camera fields stop riding along to every visitor.
Watch the two warnings this tool raises. A long edge past 4096 px and a payload past 400 KB both mean the file was exported for print or a screenshot dump rather than for a web page.

Frequently Asked Questions

Does this tool decode my image?

No. The tool reads the header region and the structural chunks of the file, then stops. No pixel buffer is allocated, nothing is drawn to a canvas, and no image element is created. A PNG read finishes after the IHDR fields and the chunk walk, and a JPEG read stops at the first frame header, which is why a 30 MB TIFF answers as fast as a 20 KB icon. The bytes live in a typed array in memory for the length of the call and are discarded right after.

Which image formats does the checker support?

Ten formats are recognized and each one returns something different. PNG gives bit depth, color type, interlace mode, pixel density, transparency, and the APNG frame count when an acTL chunk is present. JPEG gives frame header dimensions, sample precision, component count, JFIF density, and the EXIF orientation tag when the file carries Exif. GIF reports the logical screen size, global palette size, and frame count, while WebP reports lossy, lossless, or extended encoding plus alpha and animation flags. BMP reads the DIB header, AVIF and HEIC read the ftyp brand and the largest ispe box, ICO reports the largest directory entry, TIFF reads width, height, and orientation from the first IFD, and SVG reads width and height attributes or falls back to viewBox.

Does anything leave my browser?

No. The file is opened through the File API and read with arrayBuffer() inside the current tab, so there is no upload, no fetch request, and no server that can see the bytes. The tool works the same with the network disconnected, which is the fastest proof you can run. Camera model, lens, and GPS values stored in EXIF stay on the machine too. Nothing is written to storage of any kind.

Why does my JPEG rotate after I resize it?

Because the rotation is stored in the EXIF orientation tag 0x0112 rather than in the pixel data. Browsers apply values 5 through 8 when they draw the photo, so a phone picture looks right on screen even though the stored pixels are still sideways. A resizer that ignores the tag writes the sideways pixels out and sets orientation to 1, which locks the wrong rotation into the file for every other viewer. This checker prints the orientation row whenever the tag exists, so you can rotate once, strip the flag, and then resize.

What dimensions should a blog hero image be?

Pick the ratio for the layout first and the pixel count for the display second. A blog hero is usually 16:9 for a full-width band or the 1200 by 630 card shape for link previews, so decide which slot the picture fills before exporting. Then size for the device pixel ratio: a 1200 pixel wide 16:9 slot at 2x wants a 2400 by 1350 source, and the 1200 by 630 card wants 2400 by 1260. Write those real numbers into the width and height attributes of the image tag, or set CSS aspect-ratio, so the browser reserves the box before the download finishes. Finish with srcset candidates for 1x and 2x and a sizes value that matches the layout, and mark the hero fetchpriority=high when it is the Largest Contentful Paint element.

How should SVGs be sized?

The viewBox attribute defines the drawing coordinate system, so a viewBox of 0 0 120 80 lays the artwork on a 120 by 80 grid no matter what box it lands in. Set the rendered size in CSS and let the browser scale it, which keeps edges crisp at any zoom level. When the root svg tag carries width and height attributes the tool reports those values, and when they are missing it falls back to the viewBox width and height and marks the source as viewBox. Width and height written as percentages cannot be resolved from the file alone, so those come back empty with a note that the container decides.

Is there a file-size limit?

The only limit is the memory your browser will give a script, because nothing is uploaded. Tens of megabytes read without trouble, and most readers walk only the first part of the buffer anyway. The limit that matters is the one your visitors pay for. A payload of 400 KB or more triggers a size warning here, and a long edge of 4096 px or more triggers a dimension warning, so fix both before the file reaches a page template.