JPEG Structure Inspector
Walks a JPEG the way a decoder does — marker by marker, from SOI to EOI — and reports what each segment is, where it starts and how many bytes it takes. The frame header (SOFn) gives the dimensions, the sample precision, the number of components and the sampling factors, and its marker number is also what decides whether the file is baseline or progressive: a browser renders a baseline file line by line and a progressive one as a whole picture that sharpens, which is a rendering decision you cannot see in any pixel. The sampling factors are turned into the familiar 4:4:4, 4:2:2 or 4:2:0 shorthand and shown raw beside it, so a soft-looking photo can be traced to chroma stored at half resolution rather than to the quality setting. The quantization tables are compared with the Annex K example tables from the standard, and where they are the standard tables scaled by libjpeg the exact quality that produced them is recovered; where they are not, the number is an average and is labelled as an estimate, because MozJPEG, Photoshop and most camera firmwares scale their tables differently or ship their own. The application segments are listed with their sizes, which is usually where the surprise lives: an ICC profile split across several APP2 chunks, an EXIF block carrying a thumbnail, an XMP packet from an editor, a Photoshop resource block, all of it counted in bytes and as a share of the file. EXIF is reported as present and sized only — the EXIF viewer on this site reads the tags themselves. The coding section adds the restart interval, the number of Huffman tables, how many scans there are and how much of the file is entropy-coded data, which is the part re-compression can actually shrink. Finally it says whether the file really ends at EOI and how many bytes follow it, since appended data is invisible to every decoder and is how a JPEG becomes a polyglot. What it will not do is decode pixels or judge visual quality, and a file cut short inside the scan is refused rather than half-read, because past the truncation point nothing that is reported can be trusted.
How to use
- Drop a .jpg on the box, or click it to pick a file. Nothing is uploaded; the bytes are read in the page.
- Read the overview first: dimensions, baseline or progressive, chroma subsampling and the estimated quality.
- Check the application segments table when a file is unexpectedly large — an ICC profile or an EXIF thumbnail can outweigh the picture in small images.
- Open the quantization tables to see the actual matrices, and whether they are the standard Annex K tables or the encoder’s own.
- Scan the marker list for anything unusual: a missing JFIF header, a stray APPn, or bytes after the EOI marker.
Frequently asked questions
- Baseline or progressive — how does the tool know, and does it matter?
- It comes from one byte. A baseline file has an SOF0 frame header, a progressive one has SOF2, and the tool reports whichever it finds rather than guessing from the picture. It matters for how the image appears while it loads: a baseline JPEG is decoded in a single top-to-bottom scan, so it fills in line by line, while a progressive JPEG is stored as several scans that refine the whole frame, so a blurry version shows up after the first few kilobytes. Progressive files are usually a few per cent smaller because their coefficients are grouped more compressibly, but they cost more CPU and memory to decode, which is why some pipelines keep baseline for very small images and thumbnails.
- Why is the quality only an estimate?
- JPEG files do not store a quality number. They store quantization tables, and the quality slider in an encoder is just a rule for generating them. libjpeg takes the example tables from Annex K of the standard and scales every coefficient by one factor derived from the slider, so that scaling can be inverted — when the tables match a scaled Annex K table exactly, the tool says so and the recovered number is the value that was actually passed to libjpeg. Photoshop, MozJPEG, Guetzli and most camera firmwares use their own tables or their own scaling, and then the best anyone can do is an average, which is why the figure is labelled an estimate. Re-saving also destroys the link: a file encoded at 90 and re-encoded at 95 has the tables of 95 and the detail of 90.
- My photo looks soft even at high quality. What should I look at?
- The chroma subsampling, which is a separate decision from quality. In 4:2:0 the two colour channels are stored at half width and half height, so a red line on a blue background, coloured text or a saturated logo edge is reconstructed from a quarter as many colour samples and looks smeared no matter how high the quality setting is. The tool derives this from the sampling factors in the frame header and shows the raw numbers next to the shorthand: luma 2×2 with 1×1 chroma is 4:2:0, luma 2×1 is 4:2:2, and all-1×1 is 4:4:4. Most encoders switch to 4:4:4 automatically above quality 90 or so, which is why the same export at 95 can look sharper than the difference in quantization alone would explain.
- The file is much bigger than the picture deserves. Where did the bytes go?
- Look at the application segments total. An ICC profile is a common culprit: a full v4 profile runs to tens of kilobytes and, because a JPEG segment can hold only 65,533 bytes, it is split across several APP2 chunks that the tool counts for you. EXIF blocks often carry an embedded thumbnail, XMP packets from editing software can be several kilobytes of XML, and Photoshop’s APP13 resource block keeps paths and slices you will never use on the web. The entropy-coded figure tells you the other half of the story — if the scan data is only 40% of the file, no amount of re-compressing the image will help, but stripping metadata will.
- What is a restart interval and why would I want one?
- A DRI segment sets a restart interval, and the encoder then writes an RST marker after every N MCUs and resets the entropy coder’s state there. That costs a little size, and it buys two things: a decoder can resynchronise after a corrupt byte instead of losing the rest of the image, and it can decode the blocks between restarts in parallel. Most web JPEGs have no restart interval at all; you see them in scanner and broadcast output, and in files produced for hardware decoders. When one is set, this tool reports the interval in MCUs, and the restart markers themselves are skipped over as part of the scan rather than listed as segments.
- Why does the tool refuse a file that my image viewer opens fine?
- Because a viewer is allowed to be forgiving and a structural report is not. If the file ends without an EOI marker, it was cut off inside the compressed data, and a decoder will show you as many rows as it managed before running out — but the marker chain has no end, so any total this tool printed would be a total of a fragment. The same applies when a segment declares a length that runs past the end of the file: everything after that point is unreadable, and reporting the segments before it as if the file were intact would be worse than saying nothing. Both cases are named errors here, as is a file that does not start with the SOI marker at all — a PNG renamed to .jpg is the usual cause.
Related tools
GIF Structure Inspector
Open a .gif and read its blocks: frame delays and disposal, loop behaviour, palettes, transparency, and how many bytes each frame really costs.
Image Posterize
Reduce a photo to N levels per channel for that flat poster-art look, with optional Floyd-Steinberg dithering and per-channel level control.
Image EXIF Viewer
Drop a photo to inspect its EXIF metadata — camera, lens, exposure, GPS — all in your browser, nothing uploaded.
Image Compressor
Compress and resize JPEG, PNG, and WebP images in your browser.
Webcam Test & Photo Capture
Check that your webcam works and take photos with a self-timer. The video never leaves your device — no upload, no recording.
Image Histogram
Drop an image to see its RGB and luminance distribution, with per-channel mean, median, and clip-point stats.