Image Online Metadata Viewer

What Image Metadata Actually Is

Every digital image is two things at once. There is the picture — the grid of pixels your eye resolves into a face, a landscape or a screenshot. And there is everything the file says about that picture: when it was made, what made it, how the exposure was set, who owns it, which colour space it assumes, and sometimes exactly where on Earth the shutter opened. That second layer is metadata, and most people never see it.

The word is plain enough — data about data — but the reality inside an image file is messier and far more interesting. Image metadata is not one thing. It is a stack of independent standards, written by different organisations across four decades, that happen to live inside the same file. A single JPEG straight out of a modern phone routinely carries four or five of these systems simultaneously, each with its own syntax, its own tag vocabulary, and its own idea of how a date should be formatted.

Understanding that stack is the difference between "my photo has some hidden information in it" and knowing precisely which block to read, which to trust, and which to strip before you publish. Here are the layers this viewer decodes, roughly in the order they appeared in history.

The container itself

Before any metadata standard gets a look in, the file has a container format: the byte-level structure that says "this is a JPEG" or "this is a PNG". The container is declared by the first handful of bytes, called the magic number or file signature. A JPEG opens with FF D8 FF. A PNG opens with the famous eight-byte sequence 89 50 4E 47 0D 0A 1A 0A. These bytes are the ground truth about what a file really is, and they are entirely independent of the filename. A file called holiday.png whose bytes begin FF D8 FF is a JPEG that somebody renamed.

The container also carries structural facts the metadata standards do not: a PNG's IHDR chunk states the width, height, bit depth, colour type and interlace method before a single pixel is decoded. A JPEG's JFIF header records the pixel density and aspect ratio. These are not optional decorations — a decoder cannot render the image without them.

EXIF — the camera's record

EXIF (Exchangeable Image File Format) is the layer most people mean when they say "photo metadata". Introduced by the Japan Electronic Industries Development Association in 1995 and now maintained as a joint standard, EXIF is what the camera writes at the moment of capture. Shutter speed, aperture, ISO, focal length, white balance, flash state, lens model, camera body, firmware version, orientation, and the timestamp — all of it lands in EXIF.

Structurally, EXIF is borrowed wholesale from TIFF. The data sits in a set of nested directories called IFDs (Image File Directories). IFD0 holds general image and camera attributes. A sub-directory, the EXIF SubIFD, holds the capture settings. The GPS IFD holds location. IFD1, when present, describes a small embedded thumbnail. This viewer shows each of those directories separately rather than flattening them, because knowing which directory a tag came from is often the point.

IPTC — the newsroom's record

The International Press Telecommunications Council defined its Information Interchange Model in 1979 — before digital photography existed — to move wire-service copy and captions between newsrooms. Adobe adopted it into Photoshop in 1994, and IPTC-IIM became the way photographers attach a caption, a credit, a byline, keywords, a copyright notice and usage terms to a picture. Where EXIF is written by a machine, IPTC is written by a human.

XMP — Adobe's extensible layer

XMP (Extensible Metadata Platform) arrived in 2001 as Adobe's answer to the limits of both. It is RDF/XML embedded directly in the file, which means it can express arbitrarily rich structures: edit history, rating, colour labels, the entire non-destructive development recipe from Lightroom, rights statements, and increasingly, AI-generation provenance. XMP is now an ISO standard and is the layer most modern software actually writes to.

ICC — the colour contract

An ICC profile is a block that tells a display or printer how to interpret the numbers in the pixels. Without it, the value "255, 0, 0" is just three numbers; with it, those numbers mean a specific, measurable red. The International Color Consortium standardised this in 1993, and an embedded profile is the difference between a photo that looks identical on your phone and your laptop, and one that looks washed out on one of them.

Why Image Metadata Matters

Metadata is invisible by default, which is precisely why it is consequential. It travels with the file, survives copying, and is read by software long after the person who made the image has forgotten it exists. Depending on who you are, that is either an asset or a liability.

For photographers

Metadata is the difference between a folder of files and a searchable archive. A photographer with 200,000 images finds the shot they need by filtering on camera body, lens, aperture, date range or keyword — all of which live in metadata. It is also how a photographer proves authorship: an embedded copyright notice and creator field, written at import and preserved through export, is the first thing an image-rights claim rests on.

Learning from metadata matters just as much. Reviewing a year of images and seeing that nearly every keeper was shot between f/2 and f/4 at 35mm tells a photographer something concrete about their own eye that no amount of theory will.

For journalists and fact-checkers

When an image surfaces claiming to show an event, metadata is one of the first things verification desks examine. A capture timestamp that predates the event, a GPS fix in the wrong country, a Software tag naming an image editor, or a complete absence of camera tags where a camera original should have them — each is a signal. None is proof on its own, because metadata can be edited, but a coherent metadata story is much harder to fake than a convincing picture.

For privacy-conscious people

The other side of the same coin. A photograph taken indoors on a phone with location services enabled can record a GPS coordinate accurate to a few metres — your home, your child's school, your workplace. Post that image somewhere that does not strip metadata and you have published your address to anyone who knows how to look. This is not hypothetical; it has been the root cause of a long list of stalking and doxxing cases.

For developers and system administrators

Metadata is an attack surface and a debugging tool at once. An image upload pipeline that trusts the Content-Type header instead of the magic bytes is one polyglot file away from a problem. A thumbnail service that mis-renders portrait photos is almost always ignoring the EXIF Orientation tag. A site whose images look flat on Safari is often stripping ICC profiles during optimisation.

For legal and compliance work

Under the GDPR, a photograph carrying a precise GPS coordinate and a timestamp is personal data about the people in it and potentially about the photographer. Organisations that publish user-submitted imagery have a concrete obligation to think about what those files carry. A quick metadata check before publication is one of the cheapest compliance controls available.

EXIF Explained Tag by Tag

EXIF is the densest and most useful block in a camera original. It is also the one most people misread, because the tag names are terse and the units are not always what you would expect. Here is what the tags you will actually encounter mean.

Identity tags — what made this image

The Software tag deserves special attention. A camera original usually shows firmware (Ver.1.01). If it instead says Adobe Photoshop 25.0 or GIMP 2.10, the file has been through an editor — which is perfectly normal, but means it is not the original and its other tags may have been rewritten.

Exposure tags — how the shot was made

These four define the exposure triangle plus the framing, and together they reconstruct almost everything about how a photograph was taken:

• ExposureTime — shutter speed in seconds, stored as a rational. A value of 0.008 is displayed as 1/125 s. Long values indicate a tripod or deliberate blur; very short values indicate bright light or fast action.
• FNumber — the aperture, as in f/2.8. Smaller numbers mean a wider opening, more light and shallower depth of field.
• ISO (or ISOSpeedRatings) — sensor sensitivity. High values mean the scene was dark; they also mean more noise, which is itself a forensic signal.
• FocalLength — in millimetres, as recorded by the lens. The companion FocalLengthIn35mmFilm normalises this across sensor sizes, which is the only way to compare a phone's 5.7mm with a full-frame 35mm.

Supporting tags fill in the rest: ExposureProgram (manual, aperture priority, landscape mode), MeteringMode, Flash (a bit-field that records not just whether the flash fired but whether it was forced, suppressed or returned a strobe reading), WhiteBalance, ExposureBiasValue and SceneCaptureType.

The three timestamps

This is the single most misunderstood part of EXIF. There is not one date, there are three, and they mean different things:

• DateTimeOriginal — when the shutter fired. This is the one people mean by "when was this taken".
• CreateDate (stored as DateTimeDigitized) — when the image was digitised. Identical to the above for a digital camera; different for a scanned negative.
• ModifyDate (stored as DateTime) — when the file was last written. An editor updates this and usually leaves the other two alone.

Orientation — the tag that breaks websites

Orientation is a number from 1 to 8 describing how the camera was held. Rather than rotating pixels, the camera records the rotation and expects the viewer to apply it. Value 1 is normal; 6 means rotate 90° clockwise; 3 means 180°; 8 means 270°. Values 2, 4, 5 and 7 add mirroring.

This is why a photo looks right on your phone and sideways on a website: the phone honours the tag and the naive image pipeline does not. If you are debugging rotated thumbnails, this tag is almost always the answer. This viewer shows both the raw orientation and the resulting display rotation in degrees.

MakerNote — the vendor black box

MakerNote is a manufacturer-private block inside EXIF where Canon, Nikon, Sony, Fujifilm and others store whatever they like: focus point coordinates, shutter actuation count, lens serial, picture style, and in some cases a second embedded preview image. The format is undocumented and differs per vendor and per model, so general-purpose parsers surface it as raw bytes rather than pretending to decode it. It is frequently the largest single block in the file.

GPS and Location Data

The GPS IFD is the part of image metadata with the most real-world consequence. When a camera or phone has a location fix and geotagging is enabled, it writes a coordinate into the file at the moment of capture.

How coordinates are actually stored

Not as the decimal number you are used to. EXIF stores latitude and longitude as three rational numbers — degrees, minutes and seconds — with a separate reference tag giving the hemisphere:

• GPSLatitude: 43, 28, 2.814
• GPSLatitudeRef: N
• GPSLongitude: 11, 53, 6.456
• GPSLongitudeRef: E

To get the decimal form, convert with degrees + minutes/60 + seconds/3600, then negate if the reference is S or W. The example above becomes 43.467448, 11.885127 — a hillside in Tuscany. This viewer does that conversion for you and shows both forms, because the raw DMS values are what is actually in the file and the decimal pair is what you paste into a map.

The supporting GPS tags

• GPSAltitude and GPSAltitudeRef — metres above or below sea level. The reference byte distinguishes the two, so ignoring it can put a photograph 400 metres underground.
• GPSTimeStamp and GPSDateStamp — the time from the satellites, always in UTC. This is enormously useful: because the camera's own clock can be wrong, the GPS time is an independent reference. A large gap between GPS time and DateTimeOriginal tells you the camera clock was mis-set.
• GPSImgDirection and GPSImgDirectionRef — the compass bearing the lens was pointing, and whether it is true or magnetic north. Combined with the coordinate, this tells you not just where the photographer stood but what they were looking at.
• GPSSpeed, GPSTrack — movement at the time of capture, written by action cameras and drones.
• GPSDOP — dilution of precision, a quality figure for the fix. Lower is better; a high value means the coordinate is a rough estimate.
• GPSMapDatum — the geodetic reference, virtually always WGS-84.
• GPSProcessingMethod — how the fix was obtained. A value of CELLID or WLAN rather than GPS means the position was estimated from cell towers or Wi-Fi networks and may be off by hundreds of metres.

How accurate is it?

A clear-sky satellite fix on modern hardware is typically accurate to 3–5 metres — enough to identify a specific building, and often a specific room-facing window. Indoors or in dense urban canyons, phones fall back to Wi-Fi and cell triangulation, which can be accurate to 20 metres or wrong by several hundred. Always check GPSProcessingMethod and GPSDOP before treating a coordinate as precise.

XMP and IPTC: The Editorial Layer

Where EXIF records what a machine observed, IPTC and XMP record what a human decided. They are where captions, credits, keywords, rights and workflow state live, and they are what picture desks, stock libraries and digital asset management systems actually read.

IPTC-IIM: the newsroom standard

The core IPTC fields have barely changed in forty years because they describe something that has not changed — what an editor needs to know about a picture:

XMP: the modern replacement

XMP is RDF/XML embedded in the file, usually wrapped in an identifiable <x:xmpmeta> packet. Because it is XML with namespaces, it can carry anything a vendor wants to define. The namespaces you will meet most often:

• dc: — Dublin Core. dc:title, dc:creator, dc:description, dc:rights, dc:subject. The lowest common denominator that nearly all software reads.
• xmp: — core properties. xmp:CreateDate, xmp:ModifyDate, xmp:CreatorTool, xmp:Rating (the 0–5 stars you set in Lightroom), xmp:Label (the colour label).
• xmpMM: — media management. DocumentID, InstanceID and DerivedFrom form a lineage chain: they let software prove that this JPEG descends from that raw file, even after renaming.
• photoshop: — the IPTC fields as Adobe re-expressed them.
• crs: — Camera Raw settings. The entire non-destructive edit recipe: exposure, contrast, curves, per-colour adjustments, crop rectangle, lens corrections. This is why a sidecar-free raw workflow still remembers your edits.
• plus: and Iptc4xmpCore: — licensing and rights frameworks used by stock agencies.

Provenance and AI disclosure

An increasingly important use of XMP is declaring how an image came to exist. The C2PA (Coalition for Content Provenance and Authenticity) specification and the related Content Credentials initiative attach a signed manifest describing the capture device, the edits applied and whether generative AI was involved. Several major camera makers and generative tools now write these. They are not yet universal, and — critically — they can be stripped by any tool that re-encodes the file, so their absence proves nothing while their presence is meaningful.

When the layers disagree

Because IPTC, XMP and EXIF can all express a caption, a date and a creator, real files often contain the same fact three times with three different values. Adobe software generally treats XMP as authoritative and mirrors it into the legacy IPTC block for compatibility; other tools do not. When it matters, read all three separately — which is precisely why this viewer never merges the segments into a single flat list.

ICC Profiles and Colour Management

An ICC profile is the least glamorous metadata block and the one most likely to be the reason your image "looks wrong on the other screen".

Pixel values are just numbers. The triple (220, 30, 40) does not describe a colour until something says which red, green and blue primaries those numbers refer to, and how the numbers map onto light output. That definition is the colour space, and an embedded ICC profile is the file's copy of it.

The common profiles

• sRGB — the safe default and the assumed space of the web. Relatively small gamut. If an image has no profile at all, nearly every browser treats it as sRGB.
• Display P3 — the wide-gamut space used by modern Apple hardware and increasingly by Android. Noticeably more saturated reds and greens. A P3 image displayed as if it were sRGB looks oversaturated; an sRGB image treated as P3 looks flat.
• Adobe RGB (1998) — a wider gamut aimed at print, common in DSLR output. Opening an Adobe RGB file in software that ignores profiles produces the classic dull, desaturated look.
• ProPhoto RGB — very wide, used inside raw editors. Not suitable for direct web delivery.
• Rec. 2020 / PQ / HLG — HDR spaces now appearing in HEIC and AVIF files.

What the profile block contains

Beyond the colour maths, the ICC header carries readable descriptive fields this viewer surfaces: the profile description string, the device manufacturer and model, the profile class, the connection space (usually XYZ or Lab), the rendering intent, the creation date and a copyright line. When you are auditing a set of images for consistency, the profile description alone usually tells you everything you need.

Why web pipelines strip it — and why that hurts

An ICC profile can be a few hundred bytes or several kilobytes. Image optimisers routinely strip it to save weight. For an image that really is sRGB, that is harmless. For a Display P3 or Adobe RGB image it is destructive: the numbers stay the same but their meaning is lost, and the browser falls back to interpreting them as sRGB. The result is the washed-out or oversaturated rendering that is very hard to debug if you do not know to look at this block.

Magic Bytes and File Signatures

A file extension is a naming convention. It is a suggestion, trivially changed, and it carries no authority whatsoever about what a file contains. The bytes at the start of the file are the actual evidence, and they are called the magic number or file signature.

Signatures you will meet

Notice that the PNG signature is cleverer than it looks. The 0D 0A and the lone 1A exist so that a PNG damaged by a text-mode file transfer — which mangles line endings — fails the check immediately rather than producing a subtly corrupt image.

Why the mismatch check matters

This viewer compares three things: the file extension, the MIME type the browser or server declared, and the MIME type implied by the actual signature bytes. When they agree, you get a match badge. When they do not, you get a warning — and that warning is worth investigating:

• Benign: somebody renamed .jpeg to .png, or a server is configured with a wrong MIME map. Very common and harmless.
• Worth checking: an "image" whose bytes say PK (a ZIP archive) or %PDF-. That file is not what it claims.
• Actively hostile: polyglot files crafted to pass an image check while being interpreted as something executable by a different parser. This is the reason every upload handler should validate signatures server-side, not extensions.

The hex and ASCII dump

The File Facts panel prints the first 64 bytes both as hexadecimal and as printable ASCII. That dump is more informative than it first appears. In a JPEG you will usually see Exif or JFIF as readable text within the first 16 bytes, telling you immediately which APP1 segment the encoder wrote. In a PNG you will see IHDR at offset 12. In a WebP you will see RIFF and WEBP. Learning to read that strip is a genuinely useful skill.

Hashes: MD5, SHA, CRC32 and Adler32

A hash is a fixed-length fingerprint computed from every byte of a file. Change one pixel, one metadata tag, even one bit, and the hash changes completely. That property makes hashes the standard way to answer three questions: are these two files identical, has this file changed, and is this the same file I was given earlier?

This viewer computes six digests over the complete raw bytes of the file — not the decoded pixels, which is an important distinction. Two visually identical images with different metadata produce entirely different hashes.

Which hash to use for what

MD5 and SHA-1 are broken for collision resistance. Researchers have produced distinct files with identical MD5 digests since 2004, and a practical SHA-1 collision was demonstrated in 2017. They remain perfectly good for spotting accidental duplicates and for matching against older databases that indexed by them — which is exactly why this tool still shows them. They are not appropriate when an adversary might benefit from a collision.

Practical uses

• Deduplication. Hash a folder of photos and identical digests mark exact duplicates. Note the limitation: a re-saved or re-compressed copy is a different file and hashes differently even though it looks the same. For visual similarity you need a perceptual hash, which is a different technique entirely.
• Chain of custody. In investigative and legal work, hashing an image on receipt and recording the SHA-256 establishes that the file produced later is the same one. This is standard digital-forensics practice.
• Verifying a download. Compare the SHA-256 shown here with the one published by the source.
• Detecting metadata edits. Hash before and after a metadata change: the pixels are untouched but the digest moves, proving the file itself was rewritten.

Formats and Where They Hide Metadata

Each container stores metadata in its own way. Knowing where a format puts things explains why some files are rich with tags and others arrive completely bare.

JPEG

A JPEG is a sequence of marker segments. Metadata rides in the application markers: APP0 holds JFIF, APP1 holds EXIF and, in a second APP1, XMP; APP2 holds the ICC profile; APP13 holds the Photoshop resource block containing IPTC-IIM. A single APP segment is capped at 64 KB, which is why large ICC profiles and long XMP packets have to be split across multiple segments — and why some naive parsers only read the first chunk.

PNG

PNG is a chunk-based format. IHDR always comes first with width, height, bit depth, colour type, compression, filter and interlace. Metadata lives in ancillary chunks: tEXt (Latin-1 key/value), iTXt (UTF-8, and where XMP is placed), zTXt (compressed text), eXIf (EXIF, only standardised in 2017 and still inconsistently written), pHYs (physical pixel dimensions), gAMA and iCCP (gamma and embedded ICC profile), and tIME. Every chunk carries its own CRC32, which is why PNG corruption is usually detected rather than silently rendered.

WebP

A RIFF container. Extended WebP files can carry EXIF, XMP and ICCP chunks alongside the image data. Simple (non-extended) WebP files cannot carry metadata at all, which is why converting a photo to WebP so often strips everything.

HEIC, HEIF and AVIF

All three are ISO Base Media File Format containers — the same box structure as MP4. Metadata sits in meta boxes, and EXIF and XMP are stored as items referenced from the item information box. These formats also natively support multiple images per file, depth maps, alpha, HDR gain maps and image sequences, so a single HEIC from a phone may contain far more than one picture. Browser support for decoding HEIC remains limited, so a preview may not render even when the metadata reads perfectly — this tool shows the metadata regardless.

TIFF and camera raw

TIFF is the format EXIF was built on, so its IFD structure is native rather than embedded. Most camera raw formats — Canon CR2, Nikon NEF, Sony ARW, Adobe DNG — are TIFF variants with vendor extensions, which is why a raw file's EXIF often reads cleanly while its image data does not. DNG in particular is a documented TIFF profile.

GIF, BMP and ICO

Minimal metadata support. GIF has comment and application extension blocks (the Netscape looping block is the famous one) but no EXIF. BMP has essentially nothing beyond its header. ICO is a directory of small images with no metadata layer.

SVG

The odd one out: a text format with no magic number. Metadata is ordinary XML — a <metadata> element, <title>, <desc>, and often an RDF block. Because SVG is markup that browsers execute, an untrusted SVG is an active content risk, not merely an image.

Why so many images have no metadata at all

If you analyse a photo saved from a social network and find nothing, that is expected behaviour. Most major platforms strip metadata on upload — partly for user privacy, partly to save bandwidth, partly because they re-encode everything into their own pipeline. Screenshots start with almost no metadata. Images exported "for web" from editors are usually stripped deliberately. An empty result is a finding in itself: it tells you the file is not a camera original.

Privacy: What Your Photos Reveal

Most people have never looked inside their own photo files. When they finally do, the reaction is usually the same: surprise at how much is there, followed by a quick audit of what they have already shared. This section is the practical version of that audit.

The inventory of what a photo can disclose

• Where you were, to within a few metres, with a compass bearing.
• When you were there, to the second, with a satellite-derived UTC cross-check.
• What device you own — make, model, lens, and sometimes the body serial number, which links every photo from that camera into one set.
• Your name, if the camera or editor was configured with an artist or copyright string.
• Your software habits — which editor, which version, which operating system.
• An older version of the image, via the embedded thumbnail. This has a real history: in a documented case, an image cropped to remove a person was published while its EXIF thumbnail still showed the uncropped original, because the editor updated the main image and not the preview.
• Your editing history, through XMP lineage identifiers that connect an exported JPEG to its source raw file.

Aggregation is the real risk

One photograph with a coordinate is a fact. Two hundred photographs with coordinates and timestamps is a pattern of life: where you sleep, where you work, when you leave, which route you take, when the house is empty, where your children go during the day. No single image discloses that. The set does. This is why the habit of checking before sharing matters more than the risk from any one file.

Which platforms strip metadata

Behaviour changes over time and by upload path, so treat this as a guide to verify rather than a guarantee:

• Usually stripped on the public image: Facebook, Instagram, X/Twitter, WhatsApp, LinkedIn, Reddit, Discord. These platforms re-encode uploads, which discards most metadata as a side effect. Note that stripping it from the file served to others does not mean the platform did not read and retain it first.
• Often preserved: Google Photos and iCloud shared links (by design — the location is a feature), Flickr (configurable and shown publicly by default), most file-sharing and cloud-storage services that transfer the original bytes, and email attachments sent at "original size".
• Always preserved: anything that copies the file verbatim — a USB transfer, an SD card, a zip archive, an AirDrop of the original.

Turning geotagging off at the source

The most reliable fix is not to write the coordinate in the first place:

• iPhone / iPad: Settings → Privacy & Security → Location Services → Camera → Never. To share individual photos without location, use the Options control at the top of the share sheet and switch Location off.
• Android: open the Camera app, go to its settings, and disable "Save location" or "Location tags" (the wording varies by manufacturer).
• Dedicated cameras: disable the built-in GPS, or unpair the phone app that supplies location over Bluetooth. Also set the artist and copyright fields deliberately rather than leaving whatever the previous owner configured.

How to Remove Image Metadata

Reading metadata and removing it are two different jobs. This page does the first; here is how to do the second properly, with the trade-offs stated honestly.

Windows

Right-click the file → Properties → Details tab → Remove Properties and Personal Information. You can create a cleaned copy or strip the original in place. It is convenient and built in, but it is not thorough: it removes the properties Windows understands and can leave XMP packets and maker notes behind.

macOS

Preview's Tools → Show Inspector lets you view EXIF and GPS and delete the location data. For a complete strip, exporting through Preview to a new file, or using the command line, is more reliable.

ExifTool — the thorough option

Phil Harvey's ExifTool is the reference implementation for this work and is what professionals use. A few commands cover most needs:

• exiftool -all= photo.jpg — remove every metadata block.
• exiftool -gps:all= photo.jpg — remove only location, keep camera settings.
• exiftool -all= -tagsfromfile @ -icc_profile photo.jpg — strip everything but put the colour profile back, so the image still renders correctly.
• exiftool -all= -r -ext jpg ./folder — recurse through a directory.

ExifTool writes _original backups by default; add -overwrite_original once you are confident.

The re-encode trick

Opening an image and re-saving it through a tool that does not preserve metadata — including many online converters and "save for web" exports — strips everything as a side effect. It works, but it also recompresses the pixels, so you lose a generation of quality. Prefer a real metadata strip when image quality matters.

What to keep

Stripping everything is not always right. Consider keeping:

• The ICC profile, unless the image is genuinely sRGB. Removing it is the single most common cause of colour shifts on the web.
• Orientation, unless you have physically rotated the pixels first. Stripping orientation from an unrotated file is how photos end up sideways.
• Copyright and creator fields, if you are the photographer. These are what support a rights claim later.

Verify afterwards

Never assume a strip worked. Run the cleaned file back through this viewer. An empty Full Metadata pane and an absent Location card are the confirmation. The file hash will also have changed, which is a useful second signal that the bytes were genuinely rewritten.

Verification and Digital Forensics

Metadata is evidence, but it is soft evidence. Every field in this report can be edited by anyone with free software and five minutes. The value is not that metadata proves things; it is that consistent metadata is laborious to fake, and inconsistencies are cheap to find.

A practical verification checklist

1. Is there any camera metadata at all? A claimed camera original with no EXIF has been through something. That something is usually a social platform, but it should be accounted for.
2. Does Software name an editor? Not proof of manipulation — almost all published photos are edited — but it establishes the file is not straight from the sensor.
3. Do the three timestamps agree?DateTimeOriginal earlier than ModifyDate is normal editing. DateTimeOriginallater than ModifyDate is not, and warrants an explanation.
4. Does GPS time match camera time? These come from independent clocks. A large unexplained gap is a strong signal.
5. Does the location match the claim? And does GPSProcessingMethod suggest a real satellite fix rather than a network estimate?
6. Does the embedded thumbnail match the main image? A mismatch can reveal the pre-edit frame.
7. Do the exposure settings fit the scene? A bright outdoor scene at ISO 6400 and f/1.4 is internally inconsistent.
8. Does the camera model support what the tags claim? A focal length the listed lens cannot produce, or a body that never shipped with that firmware, is a fabrication signal.
9. Record the SHA-256. Before doing anything else, so you can prove later which exact file you examined.

What metadata cannot tell you

It cannot tell you whether the content of a photograph is true. A completely unedited, perfectly consistent, richly geotagged image can still be a photograph of a staged scene. Metadata establishes provenance of the file, not honesty of the subject. Equally, an absence of metadata is not evidence of deception — it is the normal state of almost every image on the internet.

Serious image verification combines metadata with reverse image search, error level analysis, noise and lighting consistency checks, shadow geometry, and old-fashioned corroboration. Metadata is the fastest of those checks and therefore usually the first, but it is never the only one.

Chain of custody

If an image may end up in a legal or disciplinary process, treat it like physical evidence: work on a copy, never the original; hash the original on receipt and record the digest with the date and who supplied it; document every tool used. The hashes this page produces are suitable for that record — and because the analysis is entirely local, examining a sensitive file here does not transmit it anywhere.

Metadata for SEO and Content Workflows

Image metadata's role in search is widely overstated and occasionally understated. Here is the realistic position.

What actually influences image search

The signals that carry real weight are outside the file: the alt attribute, the descriptive filename, the caption and surrounding text, the page title, structured data, and inclusion in an image sitemap. No EXIF tag substitutes for a good alt attribute.

That said, embedded metadata is not ignored. Google has explicitly documented support for IPTC photo metadata for rights and licensing: the Creator, Credit Line, Copyright Notice, Web Statement of Rights and Licensor URL fields can drive the licensable badge and the rights panel in Google Images. For stock photographers and agencies that is a direct commercial benefit, and it is achieved purely by writing the right IPTC fields before publishing.

Metadata and page performance

Metadata has weight. A camera JPEG can easily carry 40–70 KB of EXIF, maker notes, an embedded thumbnail and an ICC profile before a single pixel is counted. On a page with thirty product photos that is megabytes of payload that contributes nothing to what the visitor sees. Since page speed genuinely is a ranking factor and directly affects Core Web Vitals, stripping unnecessary metadata from web images is a real optimisation — provided you keep the ICC profile and orientation.

A sensible publishing workflow

1. Keep the full original, metadata intact, in your archive. That is your provenance record.
2. Write the editorial fields you want to persist — creator, copyright, caption, licensing URL — into IPTC/XMP.
3. Export a web derivative: resize, compress, strip EXIF, maker notes and the embedded thumbnail; keep ICC and the rights fields.
4. Verify the derivative in a metadata viewer before it ships. Confirm that GPS is gone, the colour profile survived, and the copyright string is present.
5. Do the descriptive work in HTML: filename, alt, caption, structured data.

Auditing a site's images

If you inherit a site, spot-checking a handful of its images is revealing. Photos still carrying a previous agency's copyright string, product shots leaking a supplier's location, or a whole gallery with stripped ICC profiles rendering flat on Safari — all of these are common, all are invisible until somebody looks, and all are fixable once found.

How to Use This Image Metadata Viewer

Loading an image

There are three ways in. Drag and drop a file onto the dashed panel. Browse to pick one with the file dialog. Or paste a URL and press Load. The first two read the file directly from your device and are the recommended path for anything private.

Reading the panels

• Preview — the decoded image, plus the embedded EXIF thumbnail when the file contains one. Compare the two; differences are informative.
• Image metadata — the summary you usually want: name, size, type, MIME, pixel dimensions and megapixels, then camera, lens, capture time, exposure and orientation when they exist.
• Location — appears only when GPS tags are present. It shows the converted decimal coordinate, every raw GPS tag, and one-click links to OpenStreetMap and Google Maps.
• File Facts — the byte-level view: source, extension, declared versus signature MIME with an agreement check, exact size, detected container, the first 64 bytes in hex and ASCII, and all six digests.
• Full metadata — every tag found, grouped under the segment it came from rather than merged into one list, with a per-segment tag count.
• Raw JSON bundle — the complete report as one JSON document.

Exporting the report

Download JSON saves the bundle as <filename>-metadata.json; Copy JSON puts it on the clipboard. The bundle includes a generator block with a timestamp, making it suitable for an audit trail or a bug report. The file is assembled in the browser and saved by the browser — it is never sent anywhere.

Starting over

Reset clears the loaded file, both inputs and every result panel, and releases the preview from memory. Loading a new image resets automatically, so you can work through a batch without pressing anything between files.

Troubleshooting and Honest Limits

"No metadata was found"

Usually correct rather than a failure. Screenshots, social-media downloads, re-encoded web images and most PNGs genuinely carry nothing. Test the tool against a photo taken directly with your own phone or camera and transferred without going through a chat app — that file will be rich.

The URL will not load

This is almost always CORS. Browsers forbid a page on one origin from reading the bytes of a resource on another origin unless that server explicitly opts in with an Access-Control-Allow-Origin header. Most image hosts do not. Because this tool has no server component, there is no proxy to fall back on — that is the direct trade-off for the privacy guarantee. Save the image locally and use the file picker; it always works.

The preview will not render

Your browser cannot decode that format for display. HEIC on non-Apple platforms, TIFF, PSD and camera raw are the usual cases. The metadata is still parsed from the raw bytes, so the report below the preview remains complete. Where the browser cannot supply pixel dimensions, the viewer falls back to the dimensions declared inside the metadata itself.

Hashes show "unavailable"

SHA digests come from the Web Crypto API, which browsers only expose in a secure context. On the live HTTPS site this always works; over plain HTTP it will not.

A very large file feels slow

Hashing reads every byte four times and runs on the main thread. A 2 MB JPEG is instant; a 200 MB TIFF takes a moment. Nothing is being uploaded during that pause — your own CPU is doing the work.

MakerNote shows raw numbers

By design. Vendor maker-note formats are undocumented and differ per manufacturer and model. Rather than guess, the viewer reports the block's presence and size and previews its bytes. For deep maker-note decoding, ExifTool is the right tool.

Values differ from another tool

Different parsers make different choices about which of several conflicting copies of a field to report, how to apply timezone offsets and whether to translate numeric codes into words. When two tools disagree, look at which segment each one read the value from. This viewer keeps segments separate specifically so that question is answerable.

Glossary of Image Metadata Terms

Frequently Asked Questions About Image Metadata