EXIF is a block of metadata stored inside the image file, alongside the pixels. A photograph taken on a phone can carry the GPS coordinates of the location, the exact timestamp, the camera make, model and serial number, the lens, the exposure settings and the software that last edited it.
That data travels with the file. Sending someone a photograph can tell them where you live.
What EXIF stores
The specification defines several hundred tags. The ones that matter in practice fall into four groups.
- Location
- GPS latitude, longitude and altitude, recorded to several decimal places. Also the direction the camera was pointing on devices with a compass. This is the field with real privacy consequences.
- Time
- The moment the shutter fired, usually to the second, plus the time zone on newer devices. It establishes where you were and when.
- Device
- Make, model, lens, and on many cameras a body serial number. A serial number links every photograph taken with that camera to the same owner, across accounts and platforms.
- Capture settings
- Aperture, shutter speed, ISO, focal length, flash state, white balance. Useful to photographers, harmless to everyone else.
Files may also carry IPTC and XMP blocks, which hold captions, keywords, copyright and editing history. Editing software writes these. They can include the name of the person who edited the file and the software licence it was edited under.
The privacy problem is specific
The abstract concern is metadata. The concrete concern is GPS coordinates in photographs taken at home.
Photographs listed for sale, posted to a forum, attached to a support ticket or emailed to a stranger frequently carry the coordinates of a residence. The coordinates are precise enough to identify a building. Nothing about the image itself reveals this, and nothing in a normal photo viewer displays it.
The device serial number is the second concern and is less obvious. It provides a stable identifier that links photographs across unrelated accounts and platforms, even when nothing else about them matches.
Which channels strip metadata and which do not
Behaviour depends on whether the service re-encodes the image or transmits the original bytes.
Services that re-encode — the major social networks, which resize every upload to their own dimensions — discard most metadata as a side effect. This protects other viewers of the post. It does not protect you from the platform, which received the original file complete with its metadata before processing it.
Channels that transmit the original file preserve everything: email attachments, cloud storage links, direct file transfer, most messaging apps when sending as a file or document rather than as a photo, and any upload form that stores what it receives.
Behaviour changes between versions and between the same app on different platforms, so verify rather than assume. The verification method is described below and takes under a minute.
How much space metadata occupies
Less than most people expect, and the honest answer is that it varies too much for a rule of thumb.
In a controlled test, adding three short EXIF tags to a JPEG increased the file from 69,078 bytes to 69,828 bytes — 750 bytes, or 1.1%. That figure is a floor, not a typical value: real camera files also carry an embedded JPEG preview thumbnail and manufacturer maker-note blocks, which are substantially larger.
The correct conclusion is that metadata removal is a privacy operation, not a compression technique. Strip it because of what it reveals, not to save bytes. If your goal is a smaller file, resize the image — that saves far more.
What breaks when you strip metadata
This is the part that is usually omitted, and it is the reason careless metadata removal produces a folder of sideways photographs.
Orientation
Phones and cameras do not rotate the pixel data when you turn the device. They store the image in the sensor's native orientation and write an EXIF Orientation tag saying how it should be displayed. Viewers read the tag and rotate on the fly.
Delete the tag without acting on it and the viewer has nothing to go on, so the image appears rotated 90 or 180 degrees. The pixels were never wrong; the instruction that made sense of them is gone.
A correct metadata remover applies the rotation to the pixel data first, then removes the tag. The result displays correctly everywhere and needs no tag. The compressor on this site does this, and so does any tool that decodes the image to a canvas before re-encoding, because the browser applies orientation during decode. Command-line tools that edit the metadata block in place generally do not, unless you ask.
Colour profile
The ICC profile is technically metadata and is frequently removed alongside EXIF. It describes how the numbers in the file map to actual colours.
Strip the profile from an image in a wide-gamut space such as Display P3 or Adobe RGB, and viewers fall back to assuming sRGB. The pixel values are unchanged, but they are now interpreted against a smaller gamut, so saturated colours flatten. Reds and greens are affected most.
Keep the ICC profile unless you know the image is already sRGB. It costs a few kilobytes and prevents a colour shift that is difficult to diagnose after the fact.
How to remove metadata
Any method that decodes and re-encodes the image removes metadata, because the metadata is not part of the pixel data being decoded.
- In the browser
- The metadata remover on this site decodes each image, applies the orientation, discards every metadata block and re-encodes. The file never leaves your device, which matters when the file is the thing you are trying to keep private. Uploading a sensitive photograph to a remote stripping service defeats the purpose of stripping it.
- Windows
- Right-click the file, choose Properties, open the Details tab, then "Remove Properties and Personal Information". It creates a cleaned copy. It does not apply orientation before removing the tag, so check the result.
- macOS
- Preview removes location data through Tools, then Show Inspector, then the GPS tab. It does not remove all metadata. For a complete strip, export a copy through Preview or use a command-line tool.
- Command line
- ExifTool is the reference implementation. It reads and writes more tag formats than anything else and is the correct tool for a large batch or a scripted workflow.
How to verify the file is clean
Do not assume the removal worked. Check.
On Windows, right-click the cleaned file, open Properties and read the Details tab: the camera, date and GPS fields should be empty. On macOS, open the file in Preview and check Tools, then Show Inspector — the GPS tab should be absent entirely rather than empty. ExifTool prints every remaining tag in one command, which is the most thorough check.
Verify the orientation at the same time. Open the cleaned file and confirm it displays the right way up. If it does not, the tool removed the tag without applying the rotation, and you need a different tool.
What stripping metadata does not protect against
Metadata removal addresses one channel of disclosure. Several others remain.
The image content itself identifies places. House numbers, street signs, vehicle registrations, distinctive views from a window and reflections in glass are all readable. No metadata operation touches any of that.
The filename frequently carries information, and it is preserved through most upload paths. Screenshots often include a browser tab bar, a taskbar, notification content or a visible username.
Finally, removal only protects the copies you clean before sending. Any copy already sent retains everything it had. Metadata removal is preventative, not retroactive.
A workflow that holds up
- Keep the originals with metadata intact, somewhere private. Capture settings and timestamps are genuinely useful, and removal is irreversible.
- Strip metadata on the copy you are about to share, not on the archive.
- Use a tool that applies orientation before removing the tag.
- Keep the ICC profile unless the image is known to be sRGB.
- Verify the result: check the metadata is gone and the image is the right way up.
- Look at the picture for the things metadata removal cannot fix.
Removing metadata from a large batch
Processing a folder rather than a file changes which method is appropriate.
A browser-based batch tool suits a set of tens to low hundreds of images. Everything is processed locally, the images never travel, and the output arrives as a ZIP. The constraint is memory: each image is decoded to raw pixels during processing, so a very large batch of very large photographs will exhaust a tab. Work in groups of fifty if the files are from a modern camera.
ExifTool suits thousands. It edits metadata blocks directly rather than re-encoding, so it is fast and it does not touch the pixel data — which is both its advantage and its trap, because it will not apply orientation for you. Direct it to do so explicitly, then verify a sample of the output rather than trusting the run.
Whichever method you use, run it into a new folder rather than in place. Metadata removal is irreversible, and a mistaken batch over your only copies cannot be undone.
Metadata worth keeping
Stripping everything is not always correct. Three fields earn their bytes.
Copyright and creator tags assert authorship inside the file itself. For a photographer publishing work, removing them discards the only claim that travels with a copied image. Keep IPTC copyright and creator, and strip location and device fields around them — most tools support selective removal.
The ICC colour profile, as described above, should stay unless the image is known to be sRGB.
Capture settings are worth keeping in your archive. Aperture, shutter speed and ISO are how you learn from your own photographs, and once removed they cannot be reconstructed. This is the argument for stripping copies rather than originals.
Screenshots and edited files carry metadata too
Metadata is not only a camera concern. A screenshot records the device and the operating system, and on some platforms the application that captured it. Editing software adds its own block: the program name, its version, and frequently the registered user or licence holder.
That last field surprises people. A photograph exported from a desktop editor can name the person whose licence produced it, even when the image was taken by someone else and contains no camera metadata at all.
Files converted between formats usually lose EXIF as a side effect, because the converter decodes pixels and writes a new container. This is incidental rather than guaranteed — some converters deliberately copy metadata across. Verify rather than relying on the conversion to clean the file.
Does metadata affect search rankings?
No. EXIF fields are not a ranking signal, and no search engine has indicated otherwise. Keywords stuffed into IPTC fields do nothing.
Two adjacent things do matter, and they are frequently confused with metadata. The alt attribute in your HTML is read by search engines and by screen readers; it lives in the markup, not in the file. The filename is also read, and a descriptive filename is mildly useful where a camera-generated one is not.
Google does read one metadata standard: IPTC licensing fields, which can surface licence information in Google Images. That is a rights display feature rather than a ranking factor, and it is relevant only if you license your photographs.
How these numbers were measured
The 750-byte figure comes from encoding one 1280 × 854 photograph twice at JPEG quality 80 through libvips 8.17.3 via sharp 0.34.5: once with three short EXIF IFD0 tags written into the file, once with metadata omitted. The exact byte lengths were 69,828 and 69,078.
That test injects a deliberately minimal metadata block. It establishes the lower bound of what metadata costs, and it is explicitly not a typical value for a camera file, which additionally carries an embedded preview thumbnail and maker notes. Measure your own files rather than generalising from this number.
The statements about platform behaviour describe the general distinction between services that re-encode uploads and channels that transmit original bytes. Specific applications change behaviour between releases, which is why this article recommends verification over assumption.