Image Metadata Viewer

Common questions

Is my photo uploaded anywhere?

No. The file is read by this page with a FileReader and parsed in your own browser, with no image or metadata upload and no account. Ordinary page loading and static usage measurement requests do not contain the chosen image, filename, metadata or coordinates. Your photo and the fields read out of it are never written to local storage either, which is deliberate: the coordinates in a holiday photo are the last thing that should outlive the tab you opened it in. The viewer restores valid column and sample preferences read-only and saves only a deliberately changed valid choice. It preserves other compatible saved fields and leaves unusable records unchanged; and the Start over button above the tool forgets both.

How do I tell whether a photo has my location in it?

The GPS cell shows decimal coordinates when valid supported EXIF latitude and longitude fields can be read; otherwise it says that no supported fix was read or that GPS is unreadable or unknown. Under the stage the reason is spelled out, with valid altitude and UTC fix time when those optional fields are present, and the stored coordinate in degrees, minutes and seconds. Latitude must have an N or S reference and longitude an E or W reference; S and W are negative. Coordinates require three nonnegative unsigned rational components with nonzero denominators, minutes and seconds below 60, and combined latitude at most 90 degrees and longitude at most 180 degrees. Missing, malformed or refused values do not produce a guessed position. Unparsed metadata may still contain location information, and this viewer does not infer a place from the picture, geocode an address or authenticate the tags.

Which formats does it read?

JPEG and PNG. A HEIC from an iPhone, a WebP, an AVIF, a TIFF or a camera raw file is named and refused rather than half read, because those keep their metadata in structures this parser does not follow and those formats are outside this viewer’s supported scope. Inside a JPEG it reads the frame header for the pixel size, the EXIF block in APP1, a JFIF density block and a plain comment segment, and it lists an XMP packet, an ICC profile or a Photoshop resource block as present without parsing them. Inside a PNG it reads IHDR, tEXt, uncompressed iTXt, pHYs, tIME, gAMA, sRGB and an eXIf chunk when one is there. A compressed zTXt or iTXt chunk is listed as present and not decompressed, because there is no decompressor in this tool, and the row says so instead of leaving a blank. Truncated or malformed supported files can produce a partial report of accepted fields with named refusals and scope notes. This parser reads structures and declared dimensions; it does not decode all image pixels or validate PNG checksums.

Why does one column say 178/100 and the other f/1.78?

Because one is the file and the other is us. EXIF stores an aperture as a rational number, a shutter as a fraction of a second, a date with colons in it and an orientation as a number from 1 to 8. The stored column displays decoded supported values, preserves rational fractions without adding a unit, escapes control characters and marks any shortened display preview, and the reading column gives the interpretation with the rule visible next to it: f/1.78, 1/200 s, 2026-07-14 11:02:33, or rotate 90 degrees clockwise to display upright. The switch in the metadata pane flips between the two, and the table under the stage shows both at once. Where there is nothing to interpret, the reading column says as stored rather than repeating the value back at you. Display text is limited to 512 Unicode code points and numeric arrays to 24 components, with the full count shown when shortened. The JSON report retains complete decoded values for accepted fields, including trailing whitespace and escaped controls; it is not a byte-for-byte copy of the original metadata block. Invalid stored date or GPS fields remain raw with a reason instead of receiving an invented interpretation.

The viewer says my photo has no metadata. Where did it go?

It means that no readable supported EXIF fields were found, rather than proof that every metadata structure is absent. Frame-header fields, PNG text and unparsed blocks are separate; malformed or refused metadata is reported with its reason. That is the normal outcome for a picture that has been through a messaging app, a social network or an export that writes a fresh file, when that workflow rewrites the image without copying its original EXIF block. A screenshot of a photo is a new image too, and carries the metadata of the screenshot rather than of the photo. This page reads a file and never changes one, so it cannot put anything back and does not claim to.

Can it strip the metadata out of my photo?

No. This tool reads and never rewrites your image, so nothing you open here is modified in any way. What it gives you instead is a report of accepted supported metadata with notes on refused or unparsed data, and a JSON export through Show JSON, Copy or Download, so you can inspect those fields before you decide whether to send that file or a re-exported copy of it. Removing the fields is a different job with different risks, and a viewer that quietly edited your only copy would be the wrong place to do it.

How large a file can I open?

The viewer has no fixed file-size cap; older versions of this page refused files over 20 MB (20,971,520 bytes), and that cap has been removed. It holds the whole file in browser memory while reading, so practical limits depend on the browser and available memory. Read failures, cancellation and a 15-second read deadline clear the current output and explain how to retry. Metadata decoding separately uses an aggregate budget of 2,097,152 field bytes, 4,096 structural records, up to 1,024 entries per TIFF directory and eight TIFF directories; fields or structures beyond those bounds are named as refused and the report is marked partial. These are parser resource bounds, not an upload limit or a guarantee that every large or malformed file can be fully read.

What happens with a damaged or hand-edited file?

It is read as far as it can be trusted and no further. An EXIF block is a TIFF directory built out of byte offsets written by whatever made the file, so every offset here is checked against the block before it is followed: an entry pointing past the end is dropped and counted, a directory claiming more entries than the block can hold is refused whole, and a chain that points back at a directory already read is followed once and stopped. Detected unsupported types, bad offsets, malformed structures and resource refusals are listed in the report, a directory pointer that missed is named with the byte it pointed at, and the reading you get is what survived those checks. A truncated JPEG segment or a PNG chunk that declares more bytes than remain stops the read at that point and says where, and a file that is not an image at all is refused with the first four bytes shown. Empty readable directories are distinguished from malformed ones. A decoded tag is still only a statement stored by a camera or editor, and a partial report is not proof that the image is intact or safe to share.

What do Copy and Download give me?

They provide the current supported metadata report as JSON, including file details, complete accepted decoded values, interpretations, source ranges, supported GPS state and reason, refusals and scope notes. They do not download viewer software or change the photo. Download hands the JSON file to the browser; it does not confirm an operating-system save. If copying or download preparation is refused, Show JSON exposes the complete current report for manual selection and copying.

Can it read AI image, ComfyUI or Stable Diffusion generation metadata?

Yes, when the generator stored it as PNG text. Stable Diffusion WebUI (AUTOMATIC1111-style) parameters text is shown whole, with the prompt, negative prompt, steps, sampler, seed and model exactly as written, and ComfyUI prompt and workflow JSON is shown whole with its node count. Show JSON, Copy and Download keep the complete text. It reads only what was stored: it cannot tell whether an image is AI-generated, recover a prompt that was stripped, draw a ComfyUI graph, or decode compressed text or XMP, and a stored prompt is not proof of how an image was made.

Does it work on a Mac, Windows, Android or in Chrome?

Yes. It is a web page, so there is nothing to install: open it in a current browser on a Mac, a Windows PC, an Android phone or an iPhone and choose a photo from that device. It is tested in Chromium, the engine behind Chrome and Edge, and in WebKit, the engine behind Safari, at desktop and phone screen sizes. It is not a browser extension or a native app, and it does not read photos from other tabs or websites.