Short answer: a photo carries five things that identify you besides the picture - GPS coordinates, camera make and model, the camera's serial number, the owner name, and the exact date and time. Strip the EXIF and XMP blocks and all five go, without touching a pixel. Drop the file into the browser cleaner on this site, or run the four-line check further down first to see which of your photos are carrying data.
One thing most guides leave out: almost every camera writes a small second copy of the picture into the metadata itself. Crop your photo before posting and that hidden copy stays at its original size, still showing whatever you cropped out. We measured it below.
Scope, stated first: this is about file metadata. Claude's text watermark is a different thing entirely - a statistical pattern in how the model chose its words, not characters or tags stored in a file. Anthropic says so plainly: “Nothing is added to the text and there are no hidden characters.” So no metadata stripper, including this one, can remove it. What Claude does attach to the images it produces is a C2PA credential, which is metadata and genuinely can be deleted. The two layers, explained →
The table below is real output from the checker further down this page, run against a synthetic 1,600×1,200 JPEG built to carry what a phone camera writes. The GPS figures are made-up coordinates, not anyone's home.
| What it holds | Real value from our test file | What a stranger does with it |
|---|---|---|
| GPS latitude / longitude | 37.789556, 122.419333 | Paste into any map and you have a street corner. This is the one that matters most. |
| Camera make and model | Aurora / Aurora X100 | Links photos across accounts: same camera, same person. |
| Body serial number | AX1-4417-2026 | Unique to one device. Survives re-uploads and ties separate posts together. |
| Owner / artist name | Alex Rivera | Often your real name, typed in once when the phone was set up and never thought about again. |
| Date and time taken | 2026:09:23 08:14:02 | Time zone, daily routine, whether you were at work or away. |
| Software used | Aurora Camera 4.2 | Weak on its own; useful when combined with the above. |
| Embedded thumbnail | 3,178 bytes, 160×120 px | A second copy of the picture. It survives cropping. See the next section. |
| Orientation | 6 | Nothing personal - and the one tag you must not delete. |
None of this is hidden in a conspiratorial sense. It is a documented part of the JPEG and PNG formats, and it is sitting in the file you are about to post. On Windows, right-click a photo and open Properties → Details to see most of it; the thumbnail is the part that view does not show you.
Cameras and phones write a small JPEG inside the EXIF block so that file browsers can show a preview without decoding the whole picture. It has a name in the specification - the IFD1 thumbnail - and its own length field. Two things about it matter here.
First, it is a full copy of the picture as it was written, and it does not follow your edits. Crop your photo to cut something out of the frame, save, and the thumbnail stays exactly as it was.
Second, almost every “check your photo metadata” guide tells you to look at Properties → Details, which does not show the thumbnail at all. So people crop, check, see nothing, and post.
We built a test to be sure rather than repeat this from memory. A 1,600×1,200 photo with a solid magenta banner across the top, then cropped to remove the banner entirely:
magenta pixels, main image (photo.jpg) : 256020 magenta pixels, main image (cropped.jpg) : 0 magenta pixels, thumbnail (thumb.jpg) : 2560 thumbnail bytes embedded in cropped.jpg : 3178
The banner is gone from the picture - zero magenta pixels left in it - and still fully present 3,178 bytes further down the same file, in the thumbnail. If you cropped out a face, a document, a street sign or a house number, that content is still in the file you are about to upload.
You can see the same thing without writing any code: search the file for a second JPEG start marker. Every JPEG begins with the two bytes FF D8. A photo with an embedded thumbnail contains that pair twice.
python -c "b=open('photo.jpg','rb').read(); print([i for i in range(len(b)-1) if b[i]==255 and b[i+1]==216])"
[0, 526]
Two markers. The first is the file. The second is the thumbnail. After a segment-level strip the same command prints [0], and the identifying strings are gone with it:
before strings={'Aurora': 4, 'Alex Rivera': 1, 'AX1-4417-2026': 1, '24-70mm': 1} markers=[0, 526]
after strings={'Aurora': 0, 'Alex Rivera': 0, 'AX1-4417-2026': 0, '24-70mm': 0} markers=[0]
That is a stronger check than trusting a tool's own success message, and it takes one line.
Here is a reader with no dependencies - Python's standard library only, nothing to install. Save it as photo_report.py, then point it at a file or a whole folder. It reads the EXIF block directly and prints what is in it, including the thumbnail that the operating system hides from you.
import os, re, struct, sys
def ifd(b, off, endian, limit=200):
e = {}
n = struct.unpack(endian + "H", b[off:off + 2])[0]
for i in range(min(n, limit)):
p = off + 2 + i * 12
tag, typ, cnt = struct.unpack(endian + "HHI", b[p:p + 8])
size = {1: 1, 2: 1, 3: 2, 4: 4, 5: 8, 7: 1}.get(typ, 1) * cnt
raw = b[p + 8:p + 12]
if size > 4:
vp = struct.unpack(endian + "I", raw)[0]
raw = b[vp:vp + size]
e[tag] = (typ, cnt, raw)
return e, struct.unpack(endian + "I", b[off + 2 + n * 12:off + 6 + n * 12])[0]
def report(path):
b = open(path, "rb").read()
i = 2
while i < len(b) - 1:
m = b[i + 1]
if m == 0xDA:
return
ln = (b[i + 2] << 8) | b[i + 3]
if m == 0xE1:
p = i + 4
if b[p:p + 6] == b"Exif\x00\x00":
p += 6
elif b[p:p + 4] not in (b"II*\x00", b"MM\x00*"):
i += 2 + ln; continue
t = b[p:i + 2 + ln]
endian = "<" if t[:2] == b"II" else ">"
d0, nxt = ifd(t, struct.unpack(endian + "I", t[4:8])[0], endian)
for tag, name in ((0x010F, "make"), (0x0110, "model"),
(0x0131, "software"), (0x013B, "owner")):
if tag in d0:
print(" %-12s %s" % (name, d0[tag][2].split(b"\x00")[0].decode()))
if 0x8769 in d0:
sub, _ = ifd(t, struct.unpack(endian + "I", d0[0x8769][2][:4])[0], endian)
if 0xA431 in sub:
print(" %-12s %s" % ("serial", sub[0xA431][2].split(b"\x00")[0].decode()))
if 0x8825 in d0:
g, _ = ifd(t, struct.unpack(endian + "I", d0[0x8825][2][:4])[0], endian)
if 0x0002 in g and 0x0004 in g:
v = lambda r: [struct.unpack(endian + "II", r[k * 8:k * 8 + 8])[0] /
max(1, struct.unpack(endian + "II", r[k * 8:k * 8 + 8])[1]) for k in range(3)]
la, lo = v(g[0x0002][2]), v(g[0x0004][2])
print(" %-12s %.6f, %.6f" % ("GPS", la[0] + la[1] / 60 + la[2] / 3600,
lo[0] + lo[1] / 60 + lo[2] / 3600))
if nxt:
f1, _ = ifd(t, nxt, endian)
if 0x0201 in f1 and 0x0202 in f1:
print(" %-12s %d bytes" % ("thumbnail", struct.unpack(endian + "I", f1[0x0202][2][:4])[0]))
else:
print(" %-12s none" % "thumbnail")
return
i += 2 + ln
for p in sys.argv[1:]:
if os.path.isdir(p):
for f in sorted(os.listdir(p)):
if f.lower().endswith((".jpg", ".jpeg", ".png")):
print("\n" + f); report(os.path.join(p, f))
else:
print("\n" + p); report(p)
Run it over the test folder used for this page:
5 image(s) in photos cropped-rot6-stripped.jpg nothing identifying cropped-rot6.jpg GPS 37.789556, 122.419333, serial AX1-4417-2026, owner Alex Rivera, thumbnail 3178 bytes, 160x120 px cropped-stripped.jpg nothing identifying cropped.jpg GPS 37.789556, 122.419333, serial AX1-4417-2026, owner Alex Rivera, thumbnail 3178 bytes, 160x120 px photo.jpg GPS 37.789556, 122.419333, serial AX1-4417-2026, owner Alex Rivera, thumbnail 3178 bytes, 160x120 px 3 of 5 carry something identifying.
Two of the five files in that folder are the same photos after cleaning, and they report nothing. That is the point of running a check rather than assuming: the folder looks uniform, and it is not.
Metadata lives in header segments ahead of the compressed image data, so deleting it never touches a pixel. Open a photo in the cleaner on this site and it removes the segments directly - nothing is uploaded, nothing is re-compressed, and it reports what it removed and what it deliberately kept.
Measured on the test photo with the orientation tag set, using the same code the browser runs:
in cropped-rot6.jpg 130121 bytes out cropped-rot6-stripped.jpg 126473 bytes removed exif kept JFIF header, JPEG image data, EXIF orientation tag saved 3648 bytes
Reading the result back with the checker above: the EXIF block went from 3,682 bytes to 34 bytes, the GPS coordinates are gone, the serial number is gone, the owner name is gone, and the embedded thumbnail is gone. The 34 bytes that remain are one tag, and there is a reason for it.
Orientation is a number from 1 to 8 telling the viewer which way up the stored pixels are. A phone held upright usually writes landscape pixels plus Orientation = 6, and every current viewer rotates the image on display. Delete the tag and the picture does not lose a pixel, but it does come back sideways - which is a visible change to the photo, made by a tool that promised not to touch it.
So this cleaner rebuilds a minimal 34-byte EXIF block holding that single tag and nothing else. After the strip above, reading the file back gives:
photo-test/cropped-rot6-stripped.jpg format JPEG, 126473 bytes EXIF block 34 bytes orientation 6 embedded thumbnail no
Orientation survived; everything identifying did not. A file whose Orientation is already 1 gets no stub at all, because there is nothing to preserve.
This is also where a real bug was found and fixed. Not every writer puts the Exif\0\0 identifier in front of the TIFF structure inside the APP1 segment - some files carry the bare TIFF header instead. The cleaner only recognised the prefixed form, so for a bare-TIFF photo it never read the Orientation tag, and such a photo came back sideways. Both forms are now read, and the regression case is part of the test suite: 25 checks, 0 failed. If a tool you use drops Orientation, that is the failure mode to look for.
The honest position is that you cannot delegate this. Some platforms strip metadata on upload and some do not, and the behaviour changes without notice - photographers have been arguing about which sites strip what for years. There is a well-known community survey of exactly that question, and it is a survey, not a specification.
Two facts hold regardless of platform:
Keep the original file. Strip metadata from a copy, not your only version, because EXIF is often the only record of when and where something was shot.
Related: the segment-by-segment walkthrough for JPEG and PNG · why Claude's watermark cannot be stripped · finding invisible characters in your own files
All of it, and it costs nothing: GPS coordinates, camera make and model, the body serial number, the owner or artist name, the original timestamp, the editing software, and the embedded thumbnail. None of it improves the photo for the person looking at it. The single exception is the EXIF Orientation tag, which you want to keep so a portrait photo does not come back sideways.
No, and cropping does something worse than leaving it alone. The metadata block is untouched by a crop, and the embedded thumbnail inside it still holds the picture as it was before you cropped - so content you deliberately cut out of the frame can still be in the file. In our test, cropping removed the banner from the image completely and left 3,178 bytes of thumbnail still showing it. Cropping is not stripping.
Some large platforms do strip metadata on upload, and photographers have been tracking which ones for years - but treat any list as a starting point rather than a guarantee, because it changes without announcement. More importantly, it only helps for that one destination. The file also travels by email, chat, cloud storage and direct download, and those paths keep everything. Test the platforms you use: post a photo with GPS in it, download your own post, and check the download.
Yes, if the photo carries GPS coordinates and it was taken at or near your home. The coordinates are decimal degrees; pasting them into any map service puts a pin on the exact spot. This is why the GPS tags are the ones worth checking before posting a photo of anything you would not want located - a room, a view from a window, an item you are selling.
Because the tool deleted the EXIF Orientation tag along with everything else. A phone held upright often stores landscape pixels plus Orientation = 6, and viewers rotate on display. Remove the tag and the raw pixels are shown as stored, so the picture is rotated 90 degrees. No pixel changed, but the photo you see did - which is why this site rebuilds a 34-byte EXIF block containing that one tag and nothing else.
It is not your name, but it is a stable device identifier, which is the part that matters. Every photo from that camera carries the same number, so two posts made months apart on different accounts can be tied to one device. Photographers raised the same concern when Flickr started displaying lens serial numbers. You cannot change the number, and it is one field in a block you can delete entirely.