Remove EXIF Data & View Photo Metadata
See every hidden field in a photo, then strip it without re-encoding a pixel.
The photo is read byte by byte in this tab — never uploadedStrip GPS location and camera data from a JPG without re-compressing
or drag & drop them here, or paste one from your clipboard (Ctrl+V). Drop several — no file cap, no size cap.
JPG · PNG · WebP
Metadata found
Choose a photo and everything hidden inside it shows up here: camera, lens, date, exposure settings, GPS coordinates, even the embedded thumbnail. Nothing is uploaded — the file is read byte by byte in this tab.
Remove the metadata
The container is rewritten and the compressed image data is copied through untouched: no re-encode, no quality loss. Most browser tools do the opposite — they push the photo through a canvas, degrade it slightly, and add their own blocks on the way out.
Orientation is normal, so stripping everything rotates nothing.
Clean files
Your cleaned files land here, with the exact byte count before and after each one.
Honest caveat: dropping every APPn block also drops the ICC colour profile and the JFIF print density. On ordinary screens you will not see it; if you work in Display P3 or print at an exact DPI, keep it in mind.
How it works
Everything runs in your browser: the image is never uploaded, there is no account, no queue and no daily limit.
Why privacy matters more here than on other tools: to remove a photo’s GPS tag, an upload service first takes possession of the photo with the GPS tag in it. Per their own documentation, TinyPNG keeps uploads for up to 48 hours and additionally logs a fingerprint of every transferred file plus your IP for 31 days; iLoveIMG retains for 2 hours; Convertio for 24 hours; ezgif for 1 hour. Uploading a photo carrying your coordinates to a server in order to delete those coordinates is a strange bargain.
Worth knowing: the thumbnail is stored separately from the main image, so a cropped or retouched photo can still carry a thumbnail of the original. It is drawn here from the file’s own bytes.
About this EXIF viewer and remover
Drop in a JPG and the page lists every metadata field the file actually carries, labelled and in plain language: when the shutter fired, which phone or camera fired it, the exposure settings, and — the field almost everyone comes here for — the GPS coordinates, if they are there. Then one button removes all of it. That removal is a byte-level rewrite of the container: the page walks the JPEG marker chain, drops the metadata segments and writes the rest back out. The compressed image is never decoded and never re-encoded, so the photo that comes out is pixel-for-pixel the photo that went in. Nothing is uploaded at any point.
This matters because a phone geotags by default and mentions it to nobody. One holiday picture can carry a latitude and longitude good to a few metres, a UTC timestamp taken from the satellites rather than your phone clock, the make and model of the device and, on interchangeable-lens cameras, an owner name and hardware serial numbers — the Exif standard has tags for exactly those. None of it is visible in the picture, and all of it travels with the file when you email it, attach it to a marketplace listing or publish it on your own site.
What makes this page different from most browser-based EXIF removers is what it refuses to do. The usual shortcut is to draw the photo into a canvas and export it again. That does delete the metadata, but it also re-compresses the image — a second generation of JPEG loss — and the canvas then writes metadata of its own back in: in testing, a 16-byte APP0 JFIF header and a 472-byte ICC profile the original never had. The byte-level strip does none of that. Measured on a test file: 2,044 bytes in, 1,498 bytes out, zero APP segments left, the image still decoding at its original 200×200, and the entropy-coded scan untouched.
Which is where privacy stops being a slogan and becomes arithmetic. Look at the transaction an upload-based metadata remover asks you to make: to delete a geotag, you first hand the geotagged original to someone else’s server. TinyPNG’s own documentation says uploads may be stored up to 48 hours, and that a fingerprint of every transferred file is logged with your IP address for 31 days. iLoveIMG documents 2 hours, Convertio 24 hours for output files, ezgif 1 hour. None of those are scandals; they are ordinary, honest engineering disclosures. They are simply the wrong shape for this one job. Here there is no server, no queue, no retention window and no account.
Two limits, stated plainly. HEIC and HEIF are not supported: an iPhone set to “High Efficiency” saves photos in that format, and decoding it in a browser needs a codec this site has deliberately not shipped yet — switch the camera to “Most Compatible”, or export a JPG copy, and this page works on the result. And removing metadata does not anonymise a photograph. The content is still the content: faces, a house number, a recognisable skyline. Forensic methods that read the sensor’s own noise pattern, or the JPEG quantisation tables, survive a metadata strip completely. This deletes what the file says about itself — real, and not a cloak.
What your phone writes into every photo, field by field
EXIF is not one thing. It is a directory structure defined by the Camera & Imaging Products Association (the Exif specification, CIPA DC-008, currently at version 2.32 with Exif 3.0 published in 2023) and embedded inside a JPEG as a marker segment. Some of it is dull housekeeping. Some of it identifies a place, a moment and a specific piece of hardware. The table below is the honest inventory, with the tag numbers so you can check any of it against the specification rather than against a blog post.
| Field | What it gives away | Where it lives |
|---|---|---|
| GPS latitude, longitude, altitude and timestamp | Where the photo was taken, typically within a few metres, plus a UTC time taken from the satellites rather than the device clock | A dedicated GPS sub-directory reached through the GPS pointer tag; the specification reserves tags 0x0000–0x001F for it |
| DateTimeOriginal (0x9003) | The second the shutter fired — enough to place a person somewhere at a time, and to line the photo up against other records | The Exif sub-directory; date and time fields are among the tags the spec requires for camera JPEGs |
| Make (0x010F) and Model (0x0110) | Which phone or camera took it. Combined with a date, it narrows a pool of possible authors very fast | The main image directory |
| CameraOwnerName (0xA430), BodySerialNumber (0xA431), LensSerialNumber (0xA435) | A name, and hardware serials that tie every photo you have ever published to the same body and lens | Standard Exif tags added in Exif 2.3 — not a proprietary extra |
| MakerNote (0x927C) | Whatever the manufacturer decided to put there. The spec describes it only as a tag for makers of Exif writers “to record any desired information”, which is why third-party utilities read a Nikon or Canon shutter count out of it | The Exif sub-directory, in an undocumented per-vendor format |
| Embedded thumbnail (0x0201 / 0x0202) | A second, smaller copy of the image — and not always of the image you think | A whole second directory (the 1st IFD) whose only job is to point at a thumbnail JPEG |
| Orientation (0x0112) | Nothing private. But it is the field that breaks things when a strip is done carelessly — see the last section | The main image directory |
| XMP, IPTC and the ICC profile | Captions, credits, copyright, editing history, the software used, and the colour profile the image was authored in | Separate marker segments alongside Exif: XMP in APP1, Photoshop and IPTC data in APP13, the ICC profile in APP2 |
Two rows there deserve more attention than they usually get. The serial-number tags are standard, not exotic: if a camera writes them, every image from that body carries the same value, which makes an anonymous photo linkable to a named one you published years ago. And MakerNote is a blob the standard explicitly declines to define, so nobody — including this page — can tell you exhaustively what your camera put in it. That is a good argument for removing the whole segment rather than editing individual fields: you cannot redact what you cannot parse.
Where metadata survives, and where nobody will tell you
There is a genre of article that lists every social network next to a tick or a cross. Treat it with suspicion, including when it agrees with you. Most platforms do not document this behaviour at all; the most authoritative published survey is the IPTC and Embedded Metadata Manifesto social-media test, and its results date from 2015–2016, which in platform terms is prehistory. The 2026 articles that fill the gap are largely published by companies selling metadata tools, and we could not reproduce their claims from primary sources. So this table only contains things the vendor itself documents.
| Where you are | What the vendor documents | What that does not cover |
|---|---|---|
| iPhone or iPad, Photos app | Apple’s Personal Safety guide: open the photo, tap the More button, “Tap Adjust Location, then tap No Location.” To share without it: “Tap the Share Sheet button, then tap Options. Turn off Location, then tap the Done button.” | The share-sheet toggle applies to that one share. It is a location control, not a full metadata strip — camera, timestamp and serial fields are a different question |
| Mac, Photos app | Apple: “Select the photos you want to change. Choose Image > Location, then choose Hide Location or Revert to Original Location.” | Same scope: location only |
| Google Photos | Google Photos Help: “Other than for partner sharing, new albums, links, conversations, and other items you share do not include location details by default,” and estimated locations “won’t be shared, even when you choose to share location details.” | This describes what a share surfaces. It is not a statement about the Exif bytes inside a file somebody downloads |
| Flickr | Flickr’s own help centre documents that EXIF is shown on the photo page and that you can change your privacy settings to hide EXIF data for all photos uploaded to your account | Hiding is a display setting on Flickr’s side, and the account owner always sees the full data |
| Windows File Explorer | Right-click → Properties → Details → “Remove Properties and Personal Information” | Demonstrably incomplete. In February 2022 the security researcher Didier Stevens showed on fully patched Windows 7, 10 and 11 that it deletes the directory entries but leaves the strings in place in the APP1 segment: a viewer stops showing “Canon”, and a raw text dump of the bytes still finds it |
| Facebook, Instagram, X, WhatsApp, TikTok | Nothing we were able to verify from the platform itself | So we are not going to assert it either way. Check your own file — that is what the viewer above is for |
There is also a structural point that the tick-and-cross tables miss entirely. “Platform X strips EXIF” describes the copy the platform re-serves to other people. It says nothing about what the platform received, read and kept when you pressed upload — those are two different files and two different privacy questions, and only the second one involves the company. Meanwhile the routes that leak most in practice are not social networks at all: an email attachment, an AirDrop, a file sent in a work chat, an image uploaded to a classified listing, a photo attached to a form, or a JPG you copied straight into your own website’s uploads folder. Those keep everything, because nothing in between re-encoded them.
The practical conclusion is the same in every case: do not reason about your file, look at it. Download the image the way a stranger would get it, drop that copy into the viewer above, and compare it against the original from your camera roll. Thirty seconds of checking beats any list, it is current by definition, and it works on the one platform combination nobody wrote an article about.
The traps in stripping metadata, and what a strip cannot do
Start with the embedded thumbnail, because it is the most under-known failure in this whole subject. A JPEG can contain a second directory whose only purpose is to point at a small preview copy of the image. Cropping software is supposed to regenerate that preview. Historically, some did not: the best-known case is from 2003, when photographs a television presenter had cropped before publishing were found to still contain thumbnails of the uncropped originals, because the editor of the day rewrote the picture and left the old preview in the metadata. The lesson survives the anecdote. If you cropped something out of a photo, a metadata strip is not a nice-to-have — it is the step that removes the copy of what you cropped.
Second trap: orientation. Phones do not rotate the pixels when you turn the camera; they record the rotation in the Orientation tag and let the viewer apply it. Browsers honour it by default — MDN gives the CSS image-orientation value from-image as the initial value, meaning “the EXIF information contained in the image is used to rotate the image appropriately.” Delete the metadata and that instruction goes with it, so a photo shot in portrait can suddenly display on its side. There is no free fix: making the pixels upright means re-encoding the JPEG, which is exactly the loss this tool exists to avoid. So check the orientation field before you strip, and if the file depends on it, rotate the photo in an editor first and save the rotation into the image itself. The same caveat applies to the ICC colour profile in APP2: a strict strip removes it, and software that finds no profile assumes sRGB, so a wide-gamut photo can shift slightly in colour.
Third, the reason the strip here is a container rewrite rather than a canvas round-trip. Re-encoding is the standard shortcut and it has three costs: a second generation of lossy compression, a canvas that writes its own JFIF and ICC segments back into your “clean” file, and output that is no longer the bytes your camera produced. The marker walk avoids all three. It is also why the file gets slightly smaller and never larger, and why you can verify the result yourself: open the original and the stripped copy side by side in a hex viewer, and the scan data will match while the APP segments are simply gone.
| Where the work happens | What happens to your photo | Source |
|---|---|---|
| TinyPNG | Uploads may be stored up to 48 hours; a fingerprint of every transferred file is logged with the IP address for 31 days | TinyPNG’s own privacy documentation |
| iLoveIMG | Files retained about 2 hours | iLoveIMG’s stated retention |
| Convertio | Output files kept 24 hours | Convertio’s stated retention |
| ezgif | Files kept about 1 hour | ezgif’s stated retention |
| This page | The file is read by JavaScript in your own tab. No request carries it anywhere, so there is nothing to retain, log or delete | Verifiable in your browser’s network panel |
Finally, the limit. Stripping metadata does not make a photograph anonymous, and anyone who implies otherwise is selling something. The visible content is untouched: faces, a house number, a street sign, a mountain on the horizon, a reflection. Beyond the content, two well-established forensic techniques ignore metadata entirely. Sensor pattern noise — the photo-response non-uniformity that Lukáš, Fridrich and Goljan described in IEEE Transactions on Information Forensics and Security in 2006 — is a per-sensor fingerprint that generally survives lossy compression and resizing. And the JPEG quantisation tables themselves carry, as Kornblum showed at DFRWS in 2008, real discriminating information about the camera model or software that wrote the file. Removing EXIF removes what the file states about itself. That is worth doing, and it is not invisibility.
FAQ
Does removing EXIF data reduce the image quality?
Not here, and the distinction is worth understanding because most web tools cannot make the same claim. A JPEG is a chain of marker segments: the metadata lives in its own segments (APP1 for EXIF and XMP, APP13 for IPTC, plus comment blocks), while the picture itself is a separate block of entropy-coded data. This page drops the metadata segments and copies the rest verbatim, so there is no decoding, no requantisation and no generation loss — the pixels are bit-identical. The common alternative, drawing the photo into a canvas and exporting it again, re-compresses everything and even writes a fresh JFIF header and ICC profile back into the file.
What is actually stored in my photo besides the location?
More than most people expect. The Exif standard defines the date and time to the second, the make and model of the device, the exposure settings, the software that last touched the file, an image unique ID, and — since Exif 2.3 — camera owner name, body serial number and lens serial number as ordinary tags. There is also MakerNote, a private blob each manufacturer fills as it likes, which is where utilities read a Nikon or Canon shutter count from. And a JPEG can hold a second, smaller copy of itself as an embedded thumbnail. The viewer above shows you what your specific file has, which is the only reliable way to know.
Does this work with iPhone HEIC photos?
No, and that is worth saying up front because HEIC is what iPhones produce by default. Apple’s High Efficiency camera setting saves photos as HEIF/HEIC, and browsers outside the Safari family cannot decode it without a WebAssembly codec, which this site has not shipped — adding one is a separate, later piece of work. Two ways around it today: set Settings → Camera → Formats to “Most Compatible” so new photos are saved as JPEG, or open the HEIC on your Mac or iPhone and export a JPG copy first. JPEG is where camera EXIF overwhelmingly lives, so in practice the JPG copy is the file you needed to clean anyway.