Paste vs attach: what happens to photo metadata

This is a different question from the ones the rest of the site answers. Pages about messaging apps, social platforms, cloud services and format conversions all ask what a destination does to a file you gave it. Here the uncertainty is upstream of that: whether a file was ever handed over. If it was not, there is no header to strip and no header to leak, and the privacy outcome was decided by an app you were not thinking about, in a step you did not consider a step.

The two completely different things "copy" can mean

Copying an image. You are looking at a photo in a viewer, an editor, a web page or a screenshot tool, and you choose copy. What generally lands on the clipboard is image data — the picture as pixels, in whatever interchange format that app and that operating system agree on. The encoded file you were looking at is not what travels. When you paste, the destination has to encode an image from that pixel data, and the result is a new file it created. MDN describes this plainly for browsers: reading and writing text, HTML and PNG image data is what browsers commonly support, and its own worked example carries a note worth remembering — even though the source image is a JPG file, what comes back out of the clipboard is a PNG. A JPEG's EXIF segment cannot survive that round trip, because the thing being encoded is a grid of pixels, not a file.

Copying a file. You are in a file manager, a Files app, a downloads list or an attachment row, and you choose copy on the file itself. Now the clipboard references the file, and pasting it hands over those exact bytes. Nothing is decoded and nothing is re-encoded, so the EXIF, XMP and IPTC payload arrives fully intact along with the original filename. This is not a quirk of one app, either: MDN documents that a DataTransfer object can expose a real FileList, readable during a drop and on the paste event, which is precisely how a paste delivers actual files to a web page.

The two look identical once pasted. Same picture, same position in the message, often the same apparent size on screen. People who have noticed that "pasting strips the metadata" have usually noticed it from the first case and then generalised it over the second, which is where it quietly stops being true.

How to tell which one you got

Do not try to tell from the preview. Look at the name and the size of the thing that landed.

1. Check the name. A pixel paste has no name to inherit, so the receiving app invents one — typically a generic placeholder along the lines of an image or clipboard label, with a number appended. A file paste keeps the real name, something like IMG_4417.JPG or lease-signed-final.jpg. The exact generated name varies by app and version, so treat "looks generated" rather than any specific string as the signal.
2. Check the format. A photo you know was a JPEG that arrives as a PNG was almost certainly re-encoded from pixels. This is the clearest single tell, and it follows directly from the clipboard behaviour MDN documents.
3. Check the size. A pixel paste of a normal photograph is often dramatically larger than the JPEG it came from, because a lossless re-encode of photographic content is expensive. Several megabytes where the original was a few hundred kilobytes is a strong hint that what you sent was built from pixels. A size that matches the file on disk byte for byte is a strong hint that it was not.
4. If your app shows you nothing, use one that does. Paste into any app that lists attachment names, types and sizes and read the answer there. One test tells you how that copy-and-paste path behaves, and you can reuse the conclusion.
5. If it matters, stop guessing. Send yourself the message, download what actually arrived, and inspect that file rather than the one you started from. The received copy is the only artefact whose contents are the real answer.

Two neighbouring pages are worth reading alongside this one. Inline pasting into mail is the single most common version of the whole problem, and the mail-specific traps — attachment conversion on send, clients that save an inline paste as a PNG carrying their own software tag — are covered in remove metadata before sending email. And because the overwhelming majority of pasted images are screenshots rather than photographs, the tags a capture actually carries are worth knowing before you decide whether any of this matters for your file: see what metadata does a screenshot contain.

What a pixel paste does, and the four things it does not do

What it does. It leaves the source file's header behind. GPS coordinates, altitude and heading, capture timestamps and their time-zone offsets, camera make, model and body serial, lens data, the software that last wrote the file, author and copyright strings, free-text comment fields, and the embedded preview thumbnail are all attributes of a file that was not transmitted. It also drops the filename, which is a genuine side benefit that header-stripping tools never give you, since names routinely carry a person, a client, a date or a place.

It does not touch the pixels. Everything visible is still visible. Faces, a monitor in the background, a document on the desk, a licence plate, a house number, a street sign, recognisable scenery, a reflection. Metadata hygiene and image content are separate problems, and paste only ever addresses the first one.

It does not change the original. The file on your device still has every tag it had, and it is still the thing that gets sent if anything later re-attaches, re-fetches or re-shares it. A library that syncs the original, a draft that re-resolves the source, an app that uploads from the camera roll rather than from the clipboard — all of those bypass the paste entirely. Paste protects one transmission, not the file.

It does not stop new metadata being written. Whatever encodes the pasted image can put whatever it likes into the result. A mail client, chat app or document editor that generates a PNG or a JPEG from clipboard pixels is free to stamp its own software identifier, a creation timestamp or a text chunk into it. PNG has several places to keep text — tEXt, iTXt and zTXt chunks, plus an eXIf chunk and a tIME stamp — and "this PNG came from the clipboard" is no guarantee that all of them are empty. The header you end up with is the destination app's, not nothing.

It does not come with a record. No app tells you which clipboard payload it used. There is no log, no setting, no confirmation. That is the real difference between a side effect and a control.

Where a paste quietly turns back into an attach

Dragging instead of pasting. Dragging a file from a folder into a compose window is a file transfer wearing a convenient gesture. The bytes go across untouched. The two actions feel equivalent and are not.

Copying the link instead of the image. Browser context menus usually offer both a copy-image option and a copy-image-address option, and the wording is similar enough that people reach for the wrong one. Sending an address sends nothing at all — the recipient fetches the original file from its server, with every tag the publisher left in it.

Clients that re-resolve the source. Some apps treat an inline paste as a placeholder and go back for the real file when you send, especially where the image is held in a synced photo library rather than as a loose file. The composer shows you a pasted image; the outbound message carries an original.

Pasting into a document rather than a message. Dropping a picture into a word processor or slide deck embeds an image object inside a container file. What the container preserves about that object is up to the application, and the document then acquires its own separate author and revision metadata. You have added a layer rather than removed one.

Pasting into a web form. A page can handle your paste in either of the two ways described above, because both are available to it — the file list if one is present, the image data otherwise. Which one a given site uses is a decision in its code that you cannot see from the page.

Common mistakes and misconceptions

"I pasted it, so it is clean." Sometimes true, never verified, and dependent on which app you copied from, which operating system you are on, and which of the two clipboard payloads was produced. A privacy outcome you cannot describe the mechanism for is a coin toss you won.

"Pasting is basically screenshotting." Both route through pixels, so both leave a file header behind, but they are not interchangeable. A screenshot captures the rendered view, at screen resolution, sometimes with surrounding interface, and is a file you can inspect before sending. A paste usually preserves the full pixel dimensions of the source and produces something you cannot inspect at all. Neither does anything about image content.

"PNG means no metadata." PNG is perfectly capable of carrying metadata, including text chunks and an EXIF chunk. A clipboard-generated PNG often has little in it, but that is a tendency of the generating app rather than a property of the format.

"Pasting is the smaller option." Usually the opposite for photographs. If a message bounces for size after you pasted rather than attached, that is the lossless re-encode, and it is also your clue about which payload was used.

"It worked last time." Clipboard behaviour belongs to the apps at both ends and to the OS between them, and all three change with updates. Last month's result is evidence about last month's software.

"The pasted copy is the only copy." It never is. The original is still in your camera roll, your downloads folder or your library, with everything in place, and that is the file your future self will grab in a hurry.

Where this site's tool fits

Worth stating plainly, because this page is about not trusting unexamined mechanisms: MetadataWipe has no clipboard support whatsoever. Its script registers dragover, dragleave and drop handlers on the drop zone, a click and an Enter or Space keypress that open the file picker, and the change event on the file input. There is no paste listener and no clipboard API call anywhere in the file. Pressing the paste shortcut over the page does nothing at all, so if you have an image on the clipboard, save or export it as a JPEG or PNG first and then drop that file in or choose it with the button.

From there it accepts image/jpeg and image/png only, one file at a time, and no other format. It runs a quick heuristic scan over the beginning of the file to report whether metadata markers are present — presence only, never values — then decodes the image, redraws it onto a canvas at its original pixel dimensions and exports a new file from that canvas, which for a JPEG is a fresh encode at the fixed quality written into the code. The clean copy arrives with -metadatawipe added to its name, so your original is left untouched and you end up with two files rather than a replaced one. All of it happens inside the page on your own device, with nothing sent anywhere.

The interesting part is that this is the same mechanism as a pixel paste: decode, redraw, re-encode, header not carried across. The difference is entirely in the control around it. You choose when it happens, you see a before-and-after check, the result is a file you hold and can inspect, and you know what the output format and dimensions are. A paste does the same work invisibly, at a moment you did not choose, with a result you cannot examine until after you have sent it.

Related guides

See also:

• Remove metadata before sending email
• What metadata does a screenshot contain?