A plain-text report, not an on-screen table
Most metadata viewers render a grid of tag names and values that you then have to squint at and screenshot. This one writes a report instead. Every photo you feed it produces a .txt file named after the image, laid out in labelled blocks: camera and lens, exposure settings, date and time, GPS location, then everything else the parser found.
That choice pays off the moment you are checking more than one photo. Reports are files, so you can keep them beside the images, diff two of them, paste one into an email, or attach it to a dispute. It also means the page has no scrolling table to fight on a phone.
Missing values are printed rather than hidden. A tag that was absent, or that held something unusable like a zero aperture, comes out as Not recorded, which is a more honest answer than an empty row. Shutter speeds are formatted the way a photographer reads them, so anything under a second becomes 1/500s and anything longer becomes 2s. Apertures print as f/2.8, rounded to two decimals.
- Drop your JPG, PNG or TIFF files onto the box above, or press Choose files. Several at once is fine; the page takes a batch.
- Press EXIF Metadata Viewer, which is the action button carrying this page’s own name.
- Download the
-exif.txtreport for each photo and open it in any text editor.
Which metadata blocks the parser actually opens
The parsing is done by exifr, a small MIT-licensed library with no runtime dependencies of its own, and it is asked for everything rather than for a curated shortlist. That switches on the main image directory, the EXIF sub-directory, the GPS directory and the interoperability directory, plus the JFIF, XMP, ICC colour-profile, IPTC and PNG header segments, with maker-note and user-comment extraction enabled on top.
One directory is deliberately not read: the second image directory, where a JPEG’s embedded thumbnail stores its own duplicate of the tags. Merging every segment into a single flat result set is what makes the report readable, and that merging mode turns the thumbnail directory off, since it would otherwise collide with the main image’s tags of the same name.
Everything the parser returns that the report has not already printed by name lands in an OTHER METADATA block at the end, sorted alphabetically. Binary blobs are summarised as a byte count rather than dumped, and structured values are serialised rather than printed as [object Object]. That block is usually where the interesting oddities live: software and firmware strings, editing history, colour space, orientation, and any IPTC caption or XMP keyword a publisher left behind.
The GPS section is written to be alarming on purpose
When a photo carries coordinates, the report does not politely list two numbers among forty others. It opens the GPS block with an explicit warning that the photo reveals your exact location, prints latitude and longitude to six decimal places, and includes a ready-made Google Maps query link so you can see the precision instead of guessing at it. A sixth decimal place of latitude is a shift of well under a metre on the ground, so this is doorway precision rather than neighbourhood precision, and the map link makes that concrete in one click.
The block then closes by telling you what to do about it, naming the metadata-stripping tool by its path. That is the whole design intent of this page: it is a label you read before you post, not a general-purpose tag browser.
When there is no location data, the section simply says so. That is worth confirming explicitly rather than inferring from an absence, especially if you are checking that a photo is safe to publish.
Photos that carry nothing at all, and why that is normal
A great many images carry no camera metadata at all, and the report says so rather than erroring or handing you an empty file: the camera, exposure and date lines all read Not recorded and the GPS block states outright that no location was found. Screenshots never had camera data to begin with. Most messaging apps and social networks strip metadata on upload. Anything that has been re-saved by an editor which rebuilds the pixels has usually lost it too.
The blunter “No EXIF metadata found in this photo.” line is reserved for the rarer case where the parser hands back nothing at all. A PNG still surrenders its IHDR header fields and most JPEGs still surrender their JFIF ones, and those land in the Other metadata block, so a stripped file is rarely a literally empty read.
That last case is what the sibling tool exploits. Remove EXIF Data from Photos does not parse and delete tags one by one; it decodes the image to a canvas bitmap and re-encodes it, and a canvas has no concept of an EXIF segment, so nothing survives by construction. Running a photo through that tool and then back through this one is the cleanest way to prove a strip worked: every camera, exposure, date and GPS line comes back as not recorded, and all that is left in Other metadata is the container’s own header fields. That is what a stripped file looks like.
Reading is not removing, and each page accepts a different list
It is worth being precise about which page does what, because the accepted file lists differ and that trips people up.
This viewer reads five extensions and writes nothing. Remove EXIF Data from Photos takes JPG and PNG only, re-encodes them, and gives you a new -no-exif copy with a JPG quality setting that defaults to 92 (PNG being lossless, that number is ignored there). EXIF Date & GPS Editor is narrower still at JPEG only, and is the surgical option: it shifts a wrong camera clock across a whole trip and can set or remove coordinates without touching the pixels.
So a TIFF can be inspected here but not stripped next door, and a PNG can be inspected and stripped but not date-shifted. If you want the same treatment for a video file instead, Video Info Viewer reports codec, container, resolution, frame rate and duration for a clip. The rest of the photo tools are on the image hub.
Batch behaviour, cancelling, and the one thing that stops a run
Photos are processed one after another, each producing its own download link, and there is no cap on how many you queue. The practical limit is your device, since every file is read into memory in turn.
There is no per-file error handling in that loop, though, so it is all or nothing: if the parser throws on one malformed image, the whole run ends and the reports already built are discarded rather than offered. A photo with no metadata is not a failure and will not do this. Cancelling mid-run has the same effect by design, since the cancel path clears the queue and empties the drop box rather than keeping partial results.