Does compressing an image for email remove EXIF data?

In this site's measured JPG re-encode, yes for the tested EXIF fields. A synthetic JPEG containing GPS coordinates, DateTimeOriginal, camera Make and Model, and Orientation was compressed to a 102,400-byte ceiling three times. Both exifr and an independent hand-written EXIF reader found no EXIF block or those fields in any output. This result applies to that re-encoding path and fixture, not every compressor or metadata family.

Does ExactSize always remove EXIF, even when the image already fits?

No. The tool passes an input through untouched when it is already below the target and already in the selected format. In a 25 MiB pass-through control, the 1,486,582-byte synthetic JPEG stayed byte-for-byte identical, and both metadata readers still found its EXIF fields.

Which metadata fields were checked?

The input fixture contained GPS latitude and longitude, DateTimeOriginal, camera Make and Model, Software, and Orientation. The two independent readers confirmed those fields on the input. Neither reader found an EXIF block in the three 100 KiB JPG outputs. XMP, ICC profiles, and other non-EXIF metadata families were not audited.

What happened to the image while it was compressed?

The synthetic 1,486,582-byte JPEG produced the same 101,828-byte, 604 × 905 JPG in three fresh-tab runs at a 102,400-byte target. The tool-reported times were 1,013, 1,150, and 1,041 ms. Output-grid RGB MAE was 18.4549 on a 0–255 channel scale; this is a pixel-error measurement, not a human visual-quality score.

Is this test proof that email providers remove or preserve EXIF?

No. The test measured the file produced by ExactSize before it is attached or sent. It did not send the file through an email service or measure what a recipient downloads.

Compress Image for Email: Does It Remove EXIF?

A JPG can carry more than the picture: GPS coordinates, capture time, camera make and model, and an orientation tag. I put known, synthetic EXIF fields into a test photo, then compressed it with ExactSize for an email-sized file. All four field groups disappeared from the three re-encoded JPGs — both an EXIF library and a separate hand-written reader found no EXIF block. There is an important exception: when the file already fits and ExactSize passes it through untouched, its EXIF stays with it.

How the test was built: a 1,600 × 1,067 canvas image was saved as JPEG, then given synthetic EXIF GPS, DateTimeOriginal, Make, Model, Software and Orientation (tag 6) fields. Before compression, two independent readers had to find the expected fields or the test would stop: the exifr library and a separate hand-written JPEG APP1/TIFF IFD parser. Three fresh browser tabs each ran the site's JPG compressor at 100 KB, which the tool interprets as 102,400 bytes. Output size came from the tool report and FileReader, then was checked against the saved file on disk. Pixel error compares an orientation-corrected source drawn to the output dimensions against the output decoded by both createImageBitmap and HTMLImageElement. A separate 25 MiB run checked the tool's pass-through path. These are local browser measurements, not remote-machine results.

The EXIF was there before compression

The fixture was designed to answer one narrow question: what happens to familiar EXIF privacy fields when ExactSize has to make a new JPG? It was not made from a personal camera photo. The GPS coordinates were synthetic test values and are deliberately not reproduced here. The capture-time string and camera identity were synthetic too.

The input carried GPS latitude and longitude, DateTimeOriginal, Make, Model, Software and Orientation. The orientation tag was numeric value 6; exifr described it as “Rotate 90 CW,” while the hand-written parser returned the raw value 6. That difference is a reader's presentation, not a mismatch about whether the tag exists. Before the compression runs began, both readers detected the expected fields in the same input file.

EXIF field	Input fixture	100 KiB JPG output, runs 1–3	Independent checks
GPS latitude and longitude	Synthetic coordinates present	No EXIF block found	exifr + hand parser
DateTimeOriginal	Synthetic capture time present	No EXIF block found	exifr + hand parser
Make and Model	Synthetic camera strings present	No EXIF block found	exifr + hand parser
Orientation	Tag 6 present	No EXIF block found	exifr + hand parser
Software	Synthetic string present	No EXIF block found	exifr + hand parser

The readers inspected the JPEG file bytes, not a preview or a browser's file-details panel. “No EXIF block found” means neither reader found a readable EXIF block in the saved output. The test did not inspect XMP, ICC profiles or every possible metadata format.

Three 100 KiB runs, the same file result

The 100 KB control in the tool means 100 × 1,024 = 102,400 bytes. The input was 1,486,582 B. All three fresh-tab runs returned the same 101,828 B JPG — 572 B under the target — at 604 × 905 pixels. The browser encoder parameter was 0.4046875 in each run; it is not a human visual-quality rating.

Run	Input B	Output B	Saved B	Output px	Encoder q	Tool ms	Wall ms	MAE	MSE	PSNR dB
1	1,486,582	101,828	1,384,754	604 × 905	0.4046875	1,013	1,234	18.4549	550.7462	20.7213
2	1,486,582	101,828	1,384,754	604 × 905	0.4046875	1,150	1,564	18.4549	550.7462	20.7213
3	1,486,582	101,828	1,384,754	604 × 905	0.4046875	1,041	1,103	18.4549	550.7462	20.7213

Output bytes matched across the compressor report, FileReader, and the saved file's size on disk. MAE is mean absolute RGB-channel difference and MSE is mean squared RGB-channel difference on the final 604 × 905 grid, with channel values on a 0–255 scale. PSNR = 10 × log10(255² ÷ MSE). Both output decode paths gave identical MAE, MSE and PSNR in each run. Tool time is the verdict's “Done in … ms”; wall time is a separate Date.now() bracket around the run. Saved bytes = input bytes − output bytes; saved percent = saved bytes ÷ input bytes × 100. The quality metrics describe this sample's encoded-and-resized pixels, not perceived image quality or total detail retained.

The output file itself was stable across the three compressions: byte count, dimensions, encoder parameter, error readings and EXIF finding all matched. The elapsed time did not. The tool's own readings spanned 1,013–1,150 ms, and the independent wall clock spanned 1,103–1,564 ms. They are readings from this machine and browser, not a time guarantee for another photo or device.

Re-encoding and passing through are not the same

ExactSize creates a new canvas-encoded image when it needs to change a file. In this test, the JPG output had no EXIF block according to either reader. But the compressor also has a pass-through path: if a file is already below the requested byte ceiling and already matches the chosen output format, it can return the original file untouched instead of encoding it again.

I tested that path once with the same synthetic JPEG and a 25 MiB ceiling. The output remained exactly 1,486,582 B — the same length as the input — and both readers still found the synthetic GPS, capture time, camera fields and Orientation. The contrast matters: do not treat “compress for email” as a promise that metadata was scrubbed. In this tested flow, the metadata result followed whether the file was re-encoded or returned unchanged.

Path	Target	Output vs input	EXIF readers	What happened
JPG re-encode ×3	100 KiB / 102,400 B	101,828 B vs 1,486,582 B	Neither found EXIF	New JPG produced by the canvas encoder
Pass-through ×1	25 MiB / 26,214,400 B	1,486,582 B vs 1,486,582 B	Both found EXIF	Original file returned unchanged

The 25 MiB pass-through control is a separate single run, not part of the three 100 KiB repetitions.

What this means before attaching a photo

If the goal is simply to make a JPG fit under a smaller byte ceiling, this run shows that ExactSize's re-encoding path also removed the tested EXIF fields. That is a side effect of this measured path, not a dedicated privacy control: the interface has no “remove metadata” switch, and a file that already qualifies may bypass re-encoding. The result also says nothing about what an email provider might do after the file is attached; no message was sent in this experiment.

If removing personal metadata is a requirement, check the final downloaded attachment itself with a metadata reader before sending. Do not infer privacy from the smaller byte count, and do not rely on the pass-through case to clean anything. If a recipient needs the capture date or camera details, remember that a re-encoded copy may no longer carry them. Orientation is another example: this fixture had Orientation 6 in its EXIF; after re-encoding the output had no EXIF block, so the tag was no longer available as metadata.

Questions this test can answer

Does compressing an image for email always erase its GPS?

Not always. Both readers stopped finding EXIF in the three tested 100 KiB re-encodes, including the synthetic GPS fields. In the 25 MiB pass-through control, those fields remained. The result depends on the processing path, and it should not be generalized to other tools or metadata families.

Were real location or camera details used?

No. The JPEG was generated specifically for this experiment and then given synthetic GPS, time, Make, Model, Software and Orientation values. There is no real person's location in the fixture. The numeric test coordinates are not published.

Does no EXIF mean the output contains no metadata of any kind?

That was not tested. The two readers checked the EXIF block and the listed EXIF tags. XMP, ICC profiles, comments and other possible metadata containers were outside this experiment, so this page does not call the output “metadata-free.”

Did you test what an email recipient sees?

No. The experiment stopped at the JPG produced by ExactSize. It did not attach or send the file, and it did not inspect a downloaded copy from an email provider. The finding is about the local compression step only.

This page measures EXIF fields in a re-encoded email-sized JPG. For a different 100KB question, the resize image to 100KB page reports dimensions, pixel retention and aspect-ratio drift; the compress image to 100KB page measures how a flat dead frame affects the byte budget and subject-region error. Those experiments did not inspect EXIF.

Measurement provenance: synthetic JPEG fixture generated locally and tagged with piexifjs; input validated by exifr and the independent _exif_reader.js parser; three fresh-tab JPG runs through site/app.js; output bytes checked by report, FileReader and disk size; EXIF checked on disk by both readers. Local Windows 11 Pro, headless Chrome 157.0.8103.78, 13 November 2026. Raw records: _px36_out.json. Only the tested EXIF fields are in scope.

Compress image for email: does EXIF stay?