Why removing metadata changes a photo's file size

Two measurements get confused constantly, so it is worth separating them before anything else. Quality is a question about the picture: is it softer, blockier, less detailed than it was? Size is a question about the file: how many bytes did the encoder need to describe those pixels? They are related but they are not the same reading, and the relationship runs in a direction that surprises people. Spending more bytes does not mean better quality than the original, and spending fewer does not automatically mean visible damage. Most importantly, neither number says anything at all about whether the GPS coordinates are gone.

The reason this matters practically is that people use the size change as a verdict. A file that shrank is taken as proof the strip worked; a file that grew is taken as proof the tool is broken, or worse, that it quietly added something. Both readings are wrong, and the second one causes people to abandon a cleaned file and send the original instead — the exact outcome they were trying to avoid.

How many bytes the metadata actually was

Start with the quantity that supposedly explains the delta, because it is smaller than almost anyone guesses and it has a hard ceiling written into the format.

In a JPEG, EXIF and the other header blocks ride in application marker segments. The JPEG specification (ITU-T T.81 / ISO/IEC 10918-1) defines the first parameter of a marker segment as a two-byte length that encodes the number of bytes in the segment, including the length parameter and excluding the two-byte marker, and its table of application-segment parameters gives that length a range of 2 to 65 535. So one application segment can carry at most 65 533 bytes of payload — call it 64 KB — and everything a writer puts in it, tags and any embedded preview thumbnail alike, has to fit inside that. A writer needing more room has to split across additional segments, and some do, but the order of magnitude does not change: a camera header carrying coordinates, a full device and lens record, timestamps, author strings and a small preview is kilobytes to a few tens of kilobytes.

The same specification, incidentally, is explicit about what those segments are for and how disposable they are: application segments are reserved for application use, and because they may be defined differently for different applications, the standard says they should be removed when the data are exchanged between application environments. Stripping them is not vandalism of the file. It is the behaviour the format anticipates.

Now put that next to the thing it is sitting beside. A photograph's compressed pixel payload is normally measured in megabytes. If the header were the whole story, every strip would produce a file within a rounding error of the original, every time, in the same direction. That is roughly what happens with a desktop utility that rewrites the header in place and leaves the compressed scan data untouched. It is not what happens in a browser.

Why a rebuild makes the number unpredictable

A browser page cannot edit the inside of a compressed JPEG. What it can do is decode the picture to pixels, draw those pixels onto a canvas, and ask the browser to write a completely new file. Read the script on this site and that is exactly what it does: the image is decoded to a bitmap, a canvas is created at the bitmap's own width and height, the pixels are drawn onto it, and the canvas is exported as a new JPEG or PNG. Nothing from the original file's bytes survives into the output. The header is gone because everything is gone and the picture has been written again from scratch.

Which means the output size is decided by the encode, and the encode has settings the original knew nothing about. For a JPEG this tool asks for quality 0.92. MDN describes that parameter as a number between 0 and 1 used for formats that support lossy compression, with the user agent falling back to its own default quality if the value is absent or out of range. So the direction of your size change comes down to a comparison you cannot see: whatever quality your original was saved at, versus the quality the rebuild uses.

• Original saved at a lower quality than the rebuild. The file grows, sometimes substantially. This is the common case for anything that has already been through another system — a photo saved out of a chat app, a picture downloaded from a social feed, a save-for-web export, an email attachment that was shrunk in transit. The rebuild is being asked to describe already-degraded pixels in more detail than the last encoder used, and it costs bytes to do that. You do not get the lost detail back; you pay for a more faithful description of what survived.
• Original saved at a higher quality than the rebuild. The file shrinks, and the drop can be large on a camera original saved at a near-maximum setting. That drop is a real lossy generation, not a header coming off.
• Original saved at something close to the rebuild. The file lands near where it started, and the small remaining difference is a mix of the removed header, the new encoder's own choices and ordinary variation. This is the case that accidentally makes the folk explanation look true.

There is one more wrinkle worth knowing, because it undermines the idea of a cleaned file as an empty one. The export is not metadata-free in the strictest sense: MDN notes that the created image is given a resolution of 96dpi for file formats that support encoding resolution metadata. A rebuild replaces a camera's header with the encoder's defaults. That is a very different proposition from a blank slate, and it is why the honest description of the output is a browser-generated file rather than a scrubbed version of your file.

PNG is lossless and still changes size

People expect JPEG to be unpredictable and expect PNG to be stable, and PNG surprises them more. The W3C PNG specification describes a format for the lossless, portable, well-compressed storage of raster images, where lossless means the data can be reconstructed exactly, bit for bit. It does not mean two encoders produce the same number of bytes. Compression comes from a filtering stage followed by deflate, a member of the LZ77 family, and the choices within those stages belong to whoever is doing the encoding. Hand the same pixels to a tuned desktop optimiser and to a browser and you can reasonably expect two different file sizes with identical pixels.

Two specific cases move the number a long way, and both are common in practice because so much of what people clean is a screenshot or a graphic rather than a photograph.

Indexed-colour images get rebuilt in full colour. The PNG specification supports indexed-colour images alongside greyscale and truecolour, and for indexed-colour the bit depth describes the number of bits in each palette index rather than the sample depth of the colours in the palette — each pixel stores a single index pointing into a table. A canvas has no equivalent concept. The HTML specification's canvas colour type defaults to unorm8, meaning 8-bit unsigned normalized components, so the picture is held as full samples per pixel and written back out that way. A tightly indexed graphic — a logo, a chart, a UI screenshot with a handful of flat colours — can come back several times its original size. Nothing went wrong; the compact representation it was using simply does not survive a trip through a pixel buffer.

Deep images get rebuilt shallower. PNG sample depths run from 1 to 16 bits. The canvas default is 8 bits per component. A 16-bit PNG rebuilt through a canvas therefore comes out at 8 bits, which usually shrinks the file and permanently discards precision that mattered to whoever produced the file. If you are handling 16-bit scans or renders, that is a reason to strip them somewhere else rather than a size curiosity.

Transparency is the mild case by comparison: an alpha channel is carried through, and because PNG is the output format for a PNG input, a transparent graphic stays transparent. A JPEG output has no alpha at all, which is why the tool keeps PNG as PNG instead of converting it.

How to read the number the tool shows you

The comparison panel in the tool gives you four facts about the cleaned copy: its name, its type, its size, and the difference from the original in bytes and as a percentage. Here is how to turn that into a decision rather than an anxiety.

1. Check the format line first. A JPEG in should give a JPEG out and a PNG in should give a PNG out. If you handed over a PNG screenshot and are startled by the size, the format line tells you whether you are looking at a lossless rebuild of flat colours — the case above — rather than anything to do with compression quality.
2. Treat growth as a statement about the original. A file that grew is telling you your input had already been compressed harder than this rebuild compresses. That is information about where the photo has been, not a fault in the cleaning.
3. Treat a large drop as a prompt to check dimensions. The rebuild does not resize: the canvas is created at the image's own width and height. So the width and height in your file properties should be identical before and after. If they are, a big drop is a compression generation. If they are not, something other than this tool resized your picture.
4. Spot-check the picture, not the number. Open both files at full zoom on a detailed region — text in frame, fabric, foliage. This is the only check that answers the quality question, and it takes seconds. The broader treatment of what re-encoding does and does not do to a photograph is in does metadata removal reduce photo quality, which is the right page for the pixel half of this.
5. Verify the metadata separately, with a reader. The size is not the result. The result is what a metadata reader says about the copy you are about to send. How to verify metadata was removed sets out the loop — clean, re-read the export rather than the original, confirm with a second reader — and that loop is what settles the question the byte count cannot.
6. Decide which copy deserves the generation. If size or fidelity genuinely matters, clean the derivative you are handing over and keep the camera original untouched and offline. You then spend the re-encode on a copy that was going to be re-encoded by its destination anyway.

Where the size change actually has consequences

Most of the time it does not matter at all and the right response is to stop looking at it. There are a few situations where it does.

A destination with a hard byte limit. Forms, portals and mail systems often refuse files over a fixed size, and a cleaned file that grew can cross a line the original sat under. The fix is ordering: get the file to the size the destination needs first, then make the metadata strip the last operation, so nothing writes to the file after the step whose only job was removing tags. Doing it the other way round hands the final write back to a resizing tool, which is free to put its own fields in the file it creates.

A picture you will edit again. Each lossy generation is permanent. If the cleaned JPEG becomes your working master and you edit and re-save it twice more, you are stacking generations for no reason. Keep the original as the master.

Anything where the encode itself is the point. Print production, archival scans, 16-bit material, graphics with precise flat colour. For these, a rebuild is the wrong instrument regardless of what the size does, and a header-rewriting utility that never decodes the pixels is the right one. That tool class is also the answer for files too large for a browser to rebuild at all.

And one non-consequence worth stating plainly, because it worries people: a changed file size does not make the photo look different when printed or displayed. The pixel dimensions are unchanged, so the physical print size at a given setting is unchanged too. The bytes moved; the picture's shape did not.

Common mistakes and misconceptions

"It got smaller, so the metadata is gone." The single most common error. A tool can shrink a file by recompressing hard while faithfully copying every EXIF, XMP and IPTC field into the output. Shrinkage is evidence about compression, not about tags.

"It got bigger, so the strip failed." Growth is the expected outcome when the input had already been compressed more aggressively than the rebuild compresses, which describes most pictures that arrived from somewhere else. Nothing failed, and nothing was inserted.

"The difference the panel shows me is the size of the metadata." Only in the coincidental case where the original's quality happened to sit near the rebuild's. In general the header contribution is buried under the encode difference, often by orders of magnitude.

"Lossless means the file should be byte-identical apart from the tags." Lossless constrains the pixels, not the byte count. Filtering and deflate choices vary between encoders, so a rebuilt PNG is a legitimately different file with identical pixels.

"I will run it through twice to get it smaller." Running a cleaned JPEG through a second rebuild spends a second generation of quality and will not reliably shrink anything, because the second encode is asked for the same quality as the first. The tool strips the suffix before re-adding it, so you will not even get a different filename out of it. There is nothing to gain and one generation to lose.

"A big file must have had more metadata in it." There is no relationship between how much a picture weighs and how much it says about you. A header with coordinates, a device serial and a timestamp is the same few tens of kilobytes whether it is attached to a small web graphic or a large scan.

"The size number is the verification step." It is a diagnostic about encoding, nothing more. The only verification is reading the metadata of the exact file you are going to send, which is the one check this page cannot do for you.

Related guides

See also:

• Does metadata removal reduce photo quality?
• How to verify metadata was removed