When one photo file contains more than one image

Almost every page on this site treats a photo as one picture with a label stuck to it, and asks what the label says about you. This page is about a different situation: a single file that contains several complete pictures, only one of which you have ever seen. Not a tiny preview — a full-resolution frame, a depth map of the room, a brightness layer, or an image a standard actually calls an Original Preservation Image. The risk here is not a coordinate in a field. It is that the picture you kept out of the file is sitting inside it, and no metadata reader you are likely to run will mention it.

MetadataWipe rebuilds one JPEG or PNG at a time from decoded pixels, in your browser — no account and no server transfer, and the file never leaves this device.

Open MetadataWipe tool

It is worth saying up front how this differs from two neighbouring problems, because the confusion is what makes people miss it.

The first neighbour is the embedded preview. A camera writes a small JPEG inside the EXIF header so galleries can scroll quickly, and that preview can carry its own copy of the tags — which is a real leak with a well-known fix, covered on why a photo's embedded thumbnail can still show old metadata after you strip it. That page is about a 160×120 image leaking fields. This page is about images large enough to be the photograph itself leaking content. The standardised type codes make the scale explicit: ExifTool's table of multi-picture image types lists Large Thumbnail entries described as VGA equivalent, full HD equivalent, 4K equivalent, 8K equivalent and 16K equivalent. A thing called a thumbnail in the specification can be a 16K image.

The second neighbour is the bundled pair. An iPhone Live Photo or an Android Motion Photo is a still plus a short video, and the question of how to clean both halves is handled in how to remove metadata from a Live Photo or Motion Photo. That case at least announces itself: the gallery shows you a play button, so you know there are two things. The cases on this page do not. Your gallery shows one photograph, your file manager shows one file, and the extra pictures are structurally invisible to both.

Where the extra pictures actually live

There are three mechanisms in common use, and they are worth telling apart because they fail differently and are removed differently.

An application segment plus a trailer. This is the main route, and it is a published standard rather than a vendor hack. The Camera & Imaging Products Association maintains CIPA DC-007, Multi-Picture Format, which its own standards list shows as published in February 2009 and revised in December 2021 and January 2025. Google's documentation for the Ultra HDR image format describes it in one sentence: Multi-Picture Format is a technique developed by CIPA for storing multiple JPEG encoded images in a single JPEG file, where one image is considered to be the primary image. The bookkeeping and the payload are stored separately. ExifTool documents the MPF tags as living in the APP2 MPF segment of a JPEG, with the MPImage data referenced from that segment stored as a JPEG trailer. In other words: a small directory near the front of the file lists what else is in there, and the actual extra pictures are appended after the end of the primary image, in the stretch of bytes a normal decoder never reaches because it has already finished.

An image serialised into XMP. XMP is a text block, and a picture can be encoded as text and dropped into it as a property. Google's Depthmap Metadata is published as an open standard for embedding depth images as XMP metadata in standard images, under the namespace http://ns.google.com/photos/1.0/depthmap/. Its reference describes properties for the format, the near and far values, the MIME types for the depth and confidence images, the units, the measure type, the manufacturer, the model, the software and the original image dimensions — and the depth data itself, which the documentation notes has to be decoded into an image before it can be scaled, cropped or rotated. So a depth map is simultaneously metadata, in that it rides in an XMP packet, and a picture, in that you can decode and look at it. Tools that strip XMP take it out; tools that preserve XMP for captions and copyright carry it forward.

A vendor trailer. Beyond the standardised route, phone makers append their own blocks to the end of JPEG files. ExifTool's trailer documentation lists information written in the JPEG trailer by some Vivo phones, by some OnePlus phones, and Google-defined information written in the trailer of JPEGs by some devices, and notes that the same payload can show up under more than one scheme at once — a motion photo video may also exist within a Samsung trailer as an embedded video file, and a gain map image may also exist in an MPF trailer as a second multi-picture image. The practical consequence of that overlap is that removing one representation does not necessarily remove the bytes, because another structure may still be pointing at them.

What the extra picture can actually be

This is where an abstract structural curiosity turns into a privacy question, because the list of standardised types is more interesting than you would guess. ExifTool's table of values for the multi-picture image type includes, alongside the Large Thumbnail sizes already mentioned, entries for Multi-frame Panorama, Multi-frame Disparity, Multi-angle, Baseline MP Primary Image, Gain Map Image, and one that deserves its own paragraph: Original Preservation Image.

Read those as answers to the question what else could be in my file.

An original the editor kept for you. Original Preservation Image is a defined slot for keeping an earlier version of the picture inside the same file as the version you are looking at. If a camera mode or an app writes one, the file you hand over contains both the frame you chose to publish and a frame you did not. Whether any particular app on your phone does this is not something you can assume either way — the point is that the container has a standard place to put it, so the possibility has to be checked rather than dismissed.
A brightness layer that encodes more than the visible frame. Google's Ultra HDR documentation describes storing a logarithmic range gain map image in a JPEG so that capable readers can combine the primary image with the gain map and render a high dynamic range result. Mechanically, the gain map is stored as a secondary image and then appended to the primary image with MPF and GContainer XMP metadata. A gain map is a greyscale picture of your scene. Its resolution is implementation-defined and Google's own guidance suggests downsampling it heavily, so it is usually coarse, but it is still a second rendering of the same frame.
A depth map of the space you were standing in. Portrait-style blur has to know what was near and what was far. That knowledge is a picture, and if it is carried in the file then the file describes the geometry of a room, not only its appearance. For an interior photo this is a category of information most people have never considered sharing.
Neighbouring frames. Multi-frame Panorama, Multi-frame Disparity and Multi-angle all imply more than one capture of the scene. More than one capture means more than one moment and, for a hand-held shot, a slightly different position — including whatever drifted into view in the frames you did not select.

Put those together and the failure mode is clear. Every other page on this site is about information describing your photo. This is about additional photography. You cannot redact it with a field-by-field approach, because it is not a field.

Why your metadata check does not see it

The uncomfortable part is that the verification habit this site recommends everywhere else — clean the file, re-read the copy you are about to send, confirm the panel is empty — does not cover this. Three reasons, and the first one is about the tool on this page.

The scanner here is deliberately shallow, and you should know its exact shape. The script is readable and its limits are not hidden: it reads at most the first 512 KB of whatever you hand it, looks through roughly the first quarter-megabyte of a JPEG for an application segment beginning with the characters Exif, and separately checks that same opening stretch for the letters GPS. It can report possible EXIF metadata, possible GPS metadata, or PNG metadata chunks. That is the whole vocabulary. There is no check for a multi-picture directory, none for bytes after the end-of-image marker, and none for a depth map in XMP — and on a four-megabyte photo, a trailing payload is not even inside the region being read. The comment in the source calls it a lightweight heuristic scan rather than forensic proof, and that is the right description. No obvious metadata detected answers the question it asked. It is not a statement about second images.

Field-list readers show you fields. A reader that prints a tidy table of tag names and values is doing exactly what you asked and will not volunteer that there are three more JPEG bitstreams in the file. Even thorough tools often need prompting: ExifTool documents an ExtractEmbedded option specifically for pulling information out of embedded images, which means a default run can be quieter than the file deserves.

Everything about the design makes the extras invisible by intent. Compatibility with old software is the whole reason trailers and secondary images are structured this way. Google states the goal directly for Ultra HDR: readers that do not support the new format read and display the conventional low dynamic range image from the file. A viewer that ignores the extra payload is not broken. It is behaving as specified. Your eyes get the same guarantee, which is why nothing looks wrong.

A workflow for finding and removing it

You do not need to become a forensic analyst. You need a cheap triage step and one reliable removal method.

Use file size as the smoke alarm. Compare the number of bytes against what the pixel dimensions would lead you to expect. A JPEG that is dramatically heavier than a photograph of that size has any business being is the classic signature of something riding along. This is the one case on this site where the byte count genuinely is a clue — note that it is a clue about a payload, still not about whether tags are present.
Suspect the source, not the subject. The files most likely to carry extras are camera-app originals straight off a recent phone, especially anything shot in a portrait, HDR, panorama or motion mode. A screenshot, a download from a social feed or an export from a web tool has usually been re-encoded by something along the way and arrives with the extras already gone.
Ask a reader to extract, not to list. If you want certainty, run a tool that can enumerate and pull out embedded images rather than one that prints a field table. Getting back more than one picture from a file you thought held one is the unambiguous answer.
Prefer a rebuild when the pixels are not precious. Decoding to pixels and writing a new file removes every one of these payloads by construction, because nothing from the original container is copied forward. That is what the tool on this page does, and it is the simplest reliable answer for a photo you are about to post or email.
Use a surgical delete when the pixels are precious. For print, archival or anything where you cannot spend a lossy generation, use a command-line utility that edits the container without decoding the picture — and remove both halves of the structure. ExifTool notes that the MPF tags are not writable, that the segment can be deleted as a group with MPF:All, and that the JPEG trailer should then be deleted too with Trailer:All. Remove only the directory and the bytes stay; remove only the trailer and you leave a directory pointing into nothing.
Make the strip the last operation. If you are also resizing or converting, do that first. Whatever writes the file last decides what the file contains, and a resizer is free to put its own structures back in.
Keep the untouched original offline. Archive rather than destroy. A hidden frame is occasionally something you actually wanted — the pre-edit version, the depth data for a reprocess — and once a rebuild has thrown it away it is not recoverable from the clean copy.

What this site's tool does to these payloads

Worth being precise, since vague claims are the thing this page is arguing against. The script decodes your file into a bitmap, creates a canvas at the bitmap's own width and height, draws the pixels onto it, and asks the browser to encode a new JPEG at quality 0.92 or a new PNG. Everything in the output was written by your browser from a pixel buffer. No part of the original file's byte stream is carried across, so there is no route by which an APP2 directory, a trailer, or an XMP packet can survive — not because the tool hunts for them, but because it never copies anything.

Three limits to state plainly. It handles JPEG and PNG only, so a HEIC straight off a phone is not a file it will accept, and HEIC containers have their own nesting conventions that this page has not tried to describe. It spends one lossy generation on a JPEG, which is the trade you are making for a structurally clean file. And the way your browser decodes a gain-map image before handing over pixels is the browser's business, so a rebuilt copy may look tonally different from the original on an HDR display even though the gain map itself is gone. Look at the rebuilt picture before you send it.

Common mistakes and misconceptions

"My metadata reader said the file was clean." It said the fields it checked were empty. Field emptiness and payload absence are two different measurements, and almost every tool reports the first while people hear the second.

"A thumbnail is a thumbnail — it is tiny." Not in this structure. The standardised type codes run up to a Large Thumbnail described as 16K equivalent. The word is a historical label for a secondary image, not a statement about its size.

"If there were another picture in there, my photo app would show it." Your photo app is a conventional reader, and conventional readers displaying only the primary image is the designed behaviour that makes the format backward compatible. Silence from your gallery is exactly what the specification promises.

"Cropping or editing the photo will get rid of it." Depends entirely on the editor. One that re-encodes from pixels drops the extras; one that edits in place and preserves the container may well carry them forward, and some apps actively maintain them because the depth map or gain map is what their own features depend on. Google's depthmap reference even sets out what has to be updated when the image is modified, which tells you that preserving-and-adjusting is an expected behaviour rather than an unusual one.

"Stripping EXIF covers it." A multi-picture directory is not EXIF, and a trailer is not even inside the part of the file a header-focused tool looks at. Removing EXIF, XMP and IPTC can leave every extra picture exactly where it was. The XMP-carried depth map is the partial exception, which is precisely what makes the category confusing.

"This is an exotic edge case." The container standard dates from 2009 and has been revised twice in the last five years, and the mainstream HDR photo format on Android is built on top of it. The structure is ordinary. What is unusual is anyone checking for it.

"I will just upload it somewhere that strips metadata." Leaving aside that this hands your original to someone else, platform processing is unpredictable here. Re-encoding usually does destroy the extras, but a platform that preserves HDR rendering has a reason to keep a gain map, and you have no visibility into which path your file took. Deciding for yourself, on your own device, is the only version of this you can verify.

Related guides

Frequently asked questions

How can a photo file contain a second full-size picture without me noticing?

Because the format was designed to allow it. JPEG carries extra pictures in two places that an ordinary viewer never looks at. The first is an application segment in the header: ExifTool documents the MPF tags as living in the APP2 MPF segment of a JPEG, with the actual image data referenced from that segment stored as a JPEG trailer — bytes parked after the end of the picture, where a conventional decoder has already stopped reading. The second is inside XMP, where an image can be serialised as text and embedded as a property; Google publishes its Depthmap Metadata as an open standard for embedding depth images as XMP metadata in standard images. In both cases the extra picture is not displayed, does not change the thumbnail in your file manager, and does not announce itself. Google documents the compatibility goal plainly for its Ultra HDR format: legacy readers that do not support it simply read and display the conventional low dynamic range image. Invisibility to old software is the feature.

Will a metadata viewer that says no EXIF found catch a hidden second image?

Not reliably, and the scanner on this site is a good example of why. Read the script and you can see its limits: it reads at most the first 512 KB of the file, searches roughly the first quarter-megabyte of a JPEG for an APP1 segment beginning with the characters Exif, and separately tests that same opening stretch for the letters GPS. It reports three things — possible EXIF, possible GPS, PNG metadata chunks. None of those correspond to an MPF directory, a JPEG trailer or a depth map in XMP, and a trailing payload at the end of a multi-megabyte file is nowhere near the window being read. So No obvious metadata detected is an honest answer to the question it asked and silence on this one. Full-featured readers do better, but even they often need to be told to look: ExifTool documents an ExtractEmbedded option for pulling information out of these embedded images, which means the default reading can be quieter than the file.

Does rebuilding the photo in this tool remove the extra images?

Yes, as a by-product of how it works, and this is the one part of the problem a browser rebuild handles well. The script decodes your file to a bitmap, draws that bitmap onto a canvas at its own width and height, and asks the browser to encode a brand-new JPEG or PNG from those pixels. Nothing is copied forward from the original bytes. There is no code path by which an APP2 directory, a trailer after the end-of-image marker, or an XMP property survives, because the output is written from a pixel buffer rather than edited in place. Two honest caveats. The tool handles JPEG and PNG only, so an unconverted HEIC from a phone is not something it will take. And how your browser decodes a gain-map image before you ever see pixels is up to that browser, so the tone and brightness of the rebuilt copy may not match the original on an HDR display even though the payload itself is gone. Check the rebuilt picture looks the way you want before you send it.

I think my photo has a hidden original inside it. What is the safest way to handle it?

Work on a copy and treat the file size as your first clue. A JPEG that is far heavier than its pixel dimensions explain is the classic signature of a second payload riding along. From there you have two routes. If you only need the picture you can see, re-encode it from pixels — any rebuild that decodes and writes a new file leaves the extra payloads behind by construction, and that includes the tool on this page. If you need to keep the compressed picture data untouched, use a command-line tool and remove both halves of the structure: ExifTool notes that the MPF tags are not writable, that the segment can be deleted as a group with MPF:All, and that the JPEG trailer should then be deleted as well with Trailer:All. Deleting one and not the other leaves either orphaned bytes or a directory pointing at them. Afterwards, verify by asking a reader to extract embedded images rather than by reading a field list, and keep the untouched original offline rather than deleting it, in case the hidden frame turns out to be something you wanted.

Remove EXIF data, GPS location and common photo metadata from a JPEG or PNG in your browser.

Try MetadataWipe free