EXIF Viewer & Metadata Remover

What EXIF is, and why it can leak your location

When a phone or camera saves a JPEG, it tucks a block of hidden data called EXIF (Exchangeable Image File Format) into the file's header, alongside the visible pixels. That block records how the shot was taken — camera make and model, lens, aperture, shutter speed, ISO, focal length and the exact date and time — and, on almost every smartphone, the GPS latitude and longitude where you were standing, accurate to a few metres.

That last part is the privacy problem. A holiday snap is harmless; a photo taken at home, in a child's bedroom, or outside your workplace quietly carries the coordinates of that place. Share the file unedited and anyone who downloads it can read the location straight out of the header — no hacking required, just a free viewer or this page. Some big platforms strip metadata when you upload, but many forums, marketplaces and personal sites do not, and files sent by email, chat or AirDrop almost always keep it intact. For a deeper walkthrough of what each field records and where the block lives in the file, see the guide EXIF & Image Metadata Explained.

Cleaning a whole folder in one go

Stripping metadata is rarely a one-photo job. It is the twenty holiday pictures you are about to post, or the six listing photos shot in your own driveway. So choose or drag in as many images as you like and each one gets its own row: the file name, the size before and after, the pixel dimensions of the cleaned copy, how many metadata fields were found, its own Download button, and a red 📍 GPS location removed badge on exactly the photos that were carrying coordinates. Once two or more have finished, a Download all (.zip) button appears and packs every cleaned copy into one archive. The entry names match the per-row buttons exactly, and two photos that arrive with the same filename are numbered apart — beach-cleaned.jpg and beach-cleaned-2.jpg — instead of one silently overwriting the other. Drop a single photo and nothing changes: you still get the full readout above, because that detail is the whole point when there is only one file to look at.

Each row ends on its own terms, and one of those endings is not a failure. A picture that never carried EXIF — a screenshot, an export from an editor that already drops it, anything saved from a service that strips on upload — says "No EXIF metadata found — nothing to strip" and still hands you the re-encoded copy. An iPhone HEIC in the batch is not re-encoded at all: its GPS location is blanked in place and its row says so (open a HEIC on its own to also blank the camera and dates). A file the browser cannot decode (renamed, damaged, or a format this browser cannot draw) fails on its own row with the reason printed, does not stop the rows behind it, and is deliberately left out of the archive: a batch that quietly loses a file is worse than one that tells you which file it lost.

The honest limits. Every photo is decoded, re-drawn and re-encoded inside this one browser tab, and the archive is assembled in memory with no streaming — four or five photos are instant, but forty multi-megapixel images cost real seconds and real memory, and a tab that runs out of it will fail rather than degrade. If it struggles, work in groups of ten. The zip also uses no compression (the store method) on purpose: JPEG and PNG payloads are already compressed, so deflating them a second time typically saves one or two percent at best and can add bytes, while costing noticeable time on a large batch.

Videos: the location hidden in an MP4 or MOV

A phone video carries the same kind of secret as a photo, in a different place. MP4, MOV and M4V files are built from nested boxes (also called atoms), and the metadata sits in the movie header box, moov, usually at the end of the file after the video data. iPhones write the place as an Apple key, com.apple.quicktime.location.ISO6709, in a meta/keys + ilst list; Android camera apps and many editors write a QuickTime ©xyz box under udta; some 3GPP-style files use a loci box with fixed-point longitude and latitude. The text form looks like +55.6761+012.5683+010.000/ — latitude 55.6761° N, longitude 12.5683° E, 10 m up: central Copenhagen, to within roughly ten metres. Next to it are usually the make and model (Apple, iPhone 15), the software version and the recording date.

Drop a video and this page reads only those boxes, a few kilobytes in total, using Blob.slice, so a 3 GB clip is inspected as quickly as a 3 MB one and never loaded into memory whole. The table lists every location, device and date field it found, and marks which ones the cleaned copy will blank.

How the video is cleaned without re-encoding

Most video tools strip metadata by re-muxing or re-encoding the whole file. This one edits it in place. Each field to remove is a box; its four-letter type is renamed to free — the standard box type that players skip — and its contents are overwritten with zero bytes. For dates, the creation and modification times in the movie, track and media headers are set to zero. Every change is the same length as what it replaces, so the cleaned file is exactly as many bytes as the original, every chunk offset in the sample tables still points at the right frame, and the video and audio data come out bit-for-bit identical. Before the Save button is enabled, the cleaned copy is parsed again from scratch; if location is still found, or the size differs, no copy is offered.

Choose Remove location (the default) to blank only the place, or Remove location, device and dates to also blank the make, model, software and every header timestamp. Re-drop the saved file to check it yourself: the table should list no location.

Video limits, honestly

• One video at a time; photos keep the batch and .zip flow described above.
• Only the boxes named here are read. A location stored elsewhere — a timed metadata track, or a subtitle track that drones, dashcams and some action cameras use for per-second GPS — is not shown and not removed.
• The keys list keeps the name of a removed Apple key (for example com.apple.quicktime.location.ISO6709) with no value attached; the coordinates themselves are zeroed.
• Codec headers inside the video stream can name the encoder (for example Lavc or an HEVC encoder string). Those are part of the picture data, which this tool deliberately never touches.
• A file whose box layout is not recognised — not an MP4/MOV, truncated, or with a box that does not fit inside its parent — gets a plain message and no cleaned copy, rather than a guessed edit that could break it.

How this tool cleans a photo

Removing metadata here does not try to surgically edit the header. Instead it re-draws the picture onto an HTML canvas and re-encodes it. A canvas holds nothing but raw pixels, so when the browser saves it back out to a file there is simply nowhere for the old EXIF, IPTC or XMP data — or the embedded colour profile — to go. The result is an image that looks the same but carries none of the original's hidden fields. It is a deliberately blunt approach, and that bluntness is what makes the outcome easy to trust.

Verify the copy is really clean

You do not have to take it on faith. Download the cleaned image, then drag that new file back into this tool. If the panel reports "No EXIF metadata found" and shows no GPS row, the strip worked. Because the cleaned file went through a canvas, it cannot contain a carried-over metadata block, so this round-trip check will pass every time — and you can use the same trick to audit files cleaned by any other tool.

The JPEG re-encode caveat (honest limits)

Stripping metadata means re-saving the image, and JPEG is lossy: the cleaned copy is re-compressed, so it is not a byte-for-byte twin of the original. This tool re-encodes JPEGs at quality 0.92, which keeps the visual loss negligible for a single pass, but re-cleaning an already-cleaned JPEG repeatedly will slowly soften it. PNG re-encoding is lossless, so PNG pixels are preserved exactly. If you specifically need the original JPEG bytes with only the header rewritten — for archival or forensic reasons — use a dedicated metadata editor that edits in place rather than re-encoding. The trade-off this tool makes is a guaranteed-clean result over bit-exact preservation. One more nicety: it reads the EXIF orientation flag and bakes the rotation into the pixels, so a sideways-shot photo stays upright after cleaning even though the orientation tag is gone.

What is read and what is removed

Format support

JPEG is the primary target because it is where cameras and phones store EXIF and GPS data, and the reader is built around the JPEG APP1/EXIF layout. PNG and WebP can be cleaned too — they are re-encoded through the same canvas — but they rarely carry EXIF to begin with. iPhone HEIC/HEIF photos take the in-place route described in the next section instead of the canvas, so you do not have to convert them first. And remember that a screenshot of a photo, or a photo already posted to a service that strips metadata, will usually have no EXIF left to find.

iPhone HEIC photos: remove the location without converting

Since iOS 11 an iPhone set to High Efficiency (the default under Settings → Camera → Formats) saves photos as HEIC, not JPEG. A HEIC is a HEIF container — the same ISO base-media box structure as an MP4 — holding the HEVC-compressed picture as one or more numbered items, and the EXIF block as another item of type Exif. This page finds that block without decoding the picture: in the top-level meta box it checks that the handler (hdlr) is pict, looks the Exif item up in the item list (iinf), and reads its file offset and length from the item-location table (iloc) — or from idat inside meta when the item is stored there. The item holds a short offset, usually the six bytes Exif\0\0, and then the same TIFF structure a JPEG carries: IFD0 with the make and model, the Exif directory with the date taken, and the GPS directory with the coordinates. A photo taken in central Copenhagen reads as 55.6761° N, 12.5683° E.

Cleaning is in place. Remove location sets the GPS directory's entry count to zero and overwrites its entries and their values with zero bytes, so the pointer from IFD0 still lands on a valid, empty directory. Remove location, device and dates also zeroes the text of the make, model, lens, software and every date and time-zone field. If the photo carries an XMP packet as a separate item (edited photos often do), its exif:GPS… values — and, in the second mode, its make, model and date values — are overwritten with spaces, which keeps the XML well-formed. Nothing is inserted or removed, so the copy is byte-for-byte the same length, every iloc offset still points at the right bytes, and the HEVC image data is identical; it is still a HEIC that Photos and other HEIC viewers open. Before Save is enabled the copy is parsed again from scratch, and the note under the button reports what that re-read found.

HEIC limits, honestly

• Chrome, Firefox and Edge on Windows — like most browsers outside Safari — cannot draw HEIC pixels, so a HEIC gets no preview here. Reading and cleaning the metadata does not need the pixels and works in all of them.
• Only the Exif item and an XMP item are read. Apple's maker note (a private block inside the Exif data) is left as it is; the EXIF standard puts the GPS position in the GPS directory, which is what this tool empties.
• A layout the parser does not know — an Exif item split across several extents, built by item reference, stored in another file, or a damaged box — gets a plain message and no file, because a guessed edit could corrupt the photo.
• In a batch of several files a HEIC gets location removal only; drop it on its own to choose the stronger mode.
• A Live Photo's motion part is a separate .MOV file with its own location; drop that too, and the video cleaner above handles it.