Disk image inspector for VHD, VMDK, QCOW2, ISO
Tool for inspecting disk images directly in your browser. Detects ISO, IMG, VHD, VHDX, VMDK, QCOW2, DMG and E01 by signature, parses MBR and GPT partition tables, identifies filesystems on each partition, parses the format-specific header and computes streaming MD5, SHA-1 and SHA-256 of the whole image.
How to inspect a disk image
Any of ISO, IMG, VHD, VHDX, VMDK, QCOW2, DMG, E01 or raw dd. Detection is by magic bytes, not extension.
Format, size, partition table, per-partition filesystem and header fields appear immediately.
Click Compute hashes to stream MD5/SHA-1/SHA-256 in one pass.
JSON for tooling or TXT for quick paste.
Read MBR, GPT, filesystem and headers from VHD, VMDK, QCOW2 and ISO
Why this inspector beats desktop alternatives
Disk Image Inspector — common questions
How does it know the format if the extension is wrong?
By reading what the file actually says about itself rather than what it is called. Each of the nine container formats leaves an identifiable mark: a VHD is recognized by the Conectix footer at the end of the file, a DMG by its UDIF trailer, an E01 by the EWF header, and QCOW2, VHDX, VMDK and ISO by their own signatures near the start. That is why an image renamed .img or downloaded without an extension is still identified correctly — and why a file that claims to be one thing and is another gets named for what it is.
Will it mount the filesystem and read my files?
No. The inspector only fingerprints the filesystem from its superblock to identify its type (FAT, NTFS, ext4 etc.). Reading file contents is the job of /iso-extractor for ISO/UDF; other filesystems are not mounted.
Does it have to read the whole image?
No, and that is what makes inspecting a large image quick. Everything the report is built from sits at fixed places: the container signature at the start or end, the MBR in the first sector, the GPT right after it, and each filesystem's superblock at a known offset inside its own partition. Reading those means a few kilobytes scattered across the file rather than a pass over all of it. So a 200 GB VMDK is described as fast as a 700 MB ISO, and the answer arrives before a copy of the file would have finished starting.
How does the QCOW2 parser handle backing files?
We parse and display the backing-file path in the header; we do not chase external backing files because they are typically on a server you do not have. The header parse alone is enough for most forensic inventory tasks.
Common scenarios this is useful for
Confirming a downloaded Linux ISO is the right edition before flashing a USB; comparing a vendor-supplied VHDX against the published checksum before deploying to a hypervisor; peeking inside a forensic E01 image to map partitions before opening it in Autopsy or FTK; spot-checking a QCOW2 snapshot to see what backing file it expects; verifying a customer-supplied DMG before running it.
What does the report contain?
Format, size, all hashes, the full MBR/GPT table with partition GUIDs decoded, per-partition filesystem type and the format-specific header fields. Generated client-side as JSON or TXT.
Will it open encrypted disks (BitLocker, LUKS)?
It detects them (FVE-FS signature for BitLocker, LUKS magic for LUKS) and shows the encryption type, but does not decrypt. Decryption requires the key/password, which is not in scope for an inspector.
Can I open the data partition in the ISO Extractor?
Yes — when an ISO9660 or UDF partition is detected, the inspector can hand the same image to /iso-extractor scoped to that partition. (Coming in v2.)
We can! Just send us a quick message with your idea. If you'd like to discuss it in detail, leave your email and we'll get back to you. You can stay anonymous.
