File Metadata Viewer
A file's extension is a suggestion. This reads the bytes and tells you what it actually is.
Drop any file here
Read in this page. Nothing is uploaded and nothing is changed.
A correct signature is not a safety check
This reports what a file is, not whether it is safe. A valid PNG can still be a PNG you did not expect, and no tool reading bytes in a browser can tell you about intent.
Everything here runs on your device. Nothing you enter is uploaded or stored.
Drop in any file and this tells you what it actually is, by reading its opening bytes rather than trusting its name. Then it parses what it found: dimensions and colour depth for images, duration and codecs for media, ID3 tags for MP3, page count and producer for PDF — and a hex dump for anything it does not recognise. Nothing is uploaded.
How to use it
- Drop or choose a file. Any type, any size.
- Read the verdict line — it names the real format and flags a wrong extension.
- Read the interpreted fields underneath.
- Press Hash file for a SHA-256, or Download report to keep the lot.
The extension is not the format
Filenames are metadata that anybody can edit and nothing verifies. Formats are the bytes at the front of the file, and they are not negotiable — a decoder reads those bytes and either recognises them or refuses. This is the gap that produces the most baffling errors in computing: an image that displays fine in your file browser and is rejected by an upload form, a video that plays in one app and not another, an attachment that will not open at all.
The verdict at the top of this tool closes that gap. It reports one of four things: the contents match the extension; the contents are something else and here is what; there is no extension but here is what the file is; or no known signature was found. That last case is not a failure — it is what plain text, CSV, JSON, SVG and source code all look like, because they have no magic number to find.
Each format gets a real parser
Detection is only half of it. Once the format is known, this walks the actual structure:
- PNG — the IHDR chunk for dimensions, bit depth, colour type and interlacing, then the full chunk list, which is where ICC profiles, text metadata and APNG animation announce themselves.
- JPEG — the SOF marker for dimensions and whether encoding is baseline or progressive, plus every APP segment so you can see that Exif, JFIF or an Adobe block is present.
- GIF — a genuine block walk. Counting occurrences of the image-separator byte would be four lines of code and wrong, because compressed pixel data contains that byte constantly; walking the blocks gives the exact frame count, the loop setting and the summed delay.
- WAV and WebP — the RIFF chunk list, so sample rate, channels, bit depth and codec come from the
fmtchunk rather than being estimated, and WebP reports lossy, lossless or extended with its alpha and animation flags. - MP4, M4A, AVIF and HEIC — the atom tree down to
mvhdfor timescale and duration,ftypfor brands, andstsdfor the codec four-character codes. - MP3 — ID3v2 frames, correctly handling the syncsafe integers in v2.4 that catch out naive readers, and all four text encodings.
- PDF — version, page count, producer, creator, whether it is encrypted, whether it has form fields.
The hex dump earns its place
At the bottom is the first 256 bytes in the classic offset / hex / ASCII layout. It is there because a metadata viewer that shows you nothing for an unfamiliar file has failed at its only job. For plain text, the ASCII column simply reads out the content. For an unknown binary, the signature is usually a recognisable string sitting in plain sight. It is the fallback that means you always leave with an answer.
What it does not do
It does not convert, repair or rename anything — it reads. It does not read inside archives, which is what ZIP Extractor is for, and it does not decode camera Exif in depth, which is what EXIF Viewer is for. It cannot tell you whether a file is malicious; a correct signature says nothing about intent, and no client-side tool should imply otherwise.
Which tool for which job
| You want | Use |
|---|---|
| To know what a file really is | This tool |
| Camera, lens and GPS data | EXIF Viewer |
| PDF author, fonts and XMP | PDF Metadata Viewer |
| To look inside an archive | ZIP Extractor |
| To find what is using disk space | File Size Analyzer |
Questions
Why would a file have the wrong extension?
Constantly, and usually innocently. Renaming a screenshot from .png to .jpg does not convert it, it just relabels it, and every "this image format is not supported" error where the image looks perfectly fine has this cause. Messaging apps re-encode what you send and keep the old name. Cameras and phones write .jpg for HEIC files under some settings. Exports from design tools get renamed by hand. And occasionally it is not innocent — an attachment called invoice.pdf whose bytes begin with MZ is a Windows executable, and that is the single most useful thing this tool can tell you.
How does detection work if the extension is ignored?
Nearly every binary format begins with a fixed byte sequence, usually called a magic number or signature. PNG files start with the eight bytes 89 50 4E 47 0D 0A 1A 0A. JPEG starts FF D8 FF. PDF is the literal text %PDF-. This tool checks around forty of them and, when several match, prefers the longest — so a RIFF container resolves to WebP or WAV rather than stopping at RIFF, and an ISO base media file resolves to AVIF or HEIC rather than generic MP4. Plain text has no signature at all, which is why it is reported as unrecognised rather than guessed at.
Why does it say "unrecognised" instead of guessing?
Because a tool that cries wolf gets ignored. Plain text, CSV, SVG, JSON, source code and dozens of other legitimate formats have no magic number, and reporting every one of them as a suspicious mismatch would train you to dismiss the warning on the day it matters. When no signature matches, the honest answer is that there is no signature, and the hex dump below usually makes the content obvious in a glance.
Does it read the whole file?
For structure, no — the first 16 megabytes, which is more than enough for every container's metadata region including a linearised PDF. Parsing a 4 GB video into memory to find its duration is a good way to crash the tab, and the duration is in the header anyway. The SHA-256 button is separate for exactly that reason — hashing genuinely does need every byte, so it is something you ask for rather than something that happens on every drop.
Last updated