Case Study: Correct EXIF Orientation and Remove GPS Metadata

Why a photo can look upright on one device and sideways on another

A camera can save a landscape-shaped pixel grid and write an EXIF orientation value that tells compatible software to rotate it during display. Many phone galleries honour that instruction automatically. A form, older application, or file-processing service that ignores it may instead show the stored pixel grid sideways.

The durable solution is not merely deleting the instruction. The pixels must be rotated first. PixelConvert applies the recorded orientation to the decoded image, then writes a new output without copying the original EXIF block. The output therefore has upright pixels and no orientation instruction that another system must understand.

This is why the problem is so reliably invisible to the person who took the photo. On the device that created the file, and in the software ecosystem built around that device, everything looks correct. The disagreement only surfaces when the file reaches a system that made a different decision about whether the tag is advisory or binding — and by then the photo is already in someone else’s hands.

What the orientation tag actually says

EXIF defines orientation as a small integer, not as an angle. The value identifies one of eight possible transformations combining rotation and mirroring, where 1 means the stored pixels are already correct and need no adjustment. Value 6, used in this test, means the image should be rotated a quarter turn clockwise for display.

Because the value selects a transformation rather than describing the image, software that does not implement the full set can get it partially right — handling the common rotations while mishandling the mirrored variants, which are rarer and arise from front-facing cameras and certain scanning paths. A file can therefore pass through several systems looking correct and then fail at one that implements fewer cases.

The practical consequence for anyone preparing an upload: you cannot predict from the file alone how a given recipient will render it. The only way to remove the uncertainty is to remove the tag’s relevance, by making the stored pixels already correct.

Measured result from the preparation endpoint

The synthetic source was a 640×420 JPEG carrying EXIF orientation 6 plus a GPS IFD containing deliberately neutral 0° N, 0° E coordinates. PixelConvert prepared it as JPEG with no resizing, cropping, or byte limit. The API returned 200, selected JPEG quality 95, and reported metadata_removed=true. Its metadata_removed warning code is expected: it tells the caller that a source metadata category was deliberately omitted from the rebuilt output.

The returned file measured 420×640, confirming that the orientation was baked into the pixels. Reopening the output found neither orientation 6 nor a GPS IFD. The result is not a claim that every possible metadata family is stripped from every unusual file; it is a controlled measurement of this EXIF-and-GPS source through the current preparation pipeline.

The dimension swap is the part worth dwelling on, because it is the observable proof rather than an assertion. A tool that merely deleted the orientation tag would return a file still measuring 640×420 — the same pixel grid, now with nothing to tell a viewer it was meant to be rotated. The output measuring 420×640 can only mean the pixel data itself was transposed.

Why the order of operations matters

There are two steps here and performing them in the wrong sequence produces a worse file than doing neither. If a tool strips metadata first and then writes the output, the orientation instruction is gone while the pixels remain in their original rotation. The image is now permanently sideways everywhere, including in the software that previously displayed it correctly.

This is a real failure mode in metadata-removal tools that treat stripping as a simple delete operation. The file comes back smaller, the privacy goal appears met, and the photograph is ruined in a way the person may not notice until a recipient points it out.

The pipeline measured here rotates first and omits second. It decodes the image, applies the recorded orientation to the pixel data, performs any requested resize or crop, and only then encodes a new file without copying the source metadata block. Each stage operates on correctly oriented pixels, which also matters for resizing — a width and height applied before rotation would be applied to the wrong axis.

What a GPS block actually contains

The GPS portion of EXIF is a structured section capable of holding considerably more than a pair of coordinates. Depending on what the capturing device recorded, it can include latitude and longitude with their hemisphere references, altitude, a timestamp, the direction the camera was pointing, and sometimes speed and positioning method.

The precision is the part people underestimate. Consumer GPS in a phone commonly resolves to within a few metres, which is enough to identify a specific building rather than a general area. A photograph taken indoors at home carries the home address in a form any image tool can read without special skill.

The test source here uses 0° N, 0° E deliberately. That location is a point in the Atlantic Ocean, chosen because it is unambiguously synthetic — it demonstrates that a populated GPS IFD was present and subsequently absent, without publishing anybody’s real position in a downloadable test file.

The individual risk from one photograph is usually modest. The risk from a set of photographs shared by the same person over time is not, because the pattern reveals where they live, work, and spend time, with timestamps attached.

What metadata removal does and does not protect

GPS coordinates, capture time, device details, editing history, and orientation can all be stored outside the visible image. Removing them can reduce accidental disclosure when a recipient only needs the image itself. It can also improve compatibility where a form rejects an unusual metadata block.

It is not anonymity. A landmark, house number, reflection, face, or document inside the pixels remains visible. A recipient can also infer context from the image content or the way it is shared. Treat metadata removal as one practical hygiene step, not a promise of complete privacy.

There is also a scope limit worth being explicit about. This measurement covers a standard JPEG EXIF block with a GPS IFD. Image files can carry other metadata families — vendor-specific maker notes, XMP packets, embedded thumbnails that were generated before an edit — and a conservative tool does not claim to have parsed and removed families it did not inspect. Where the consequences of a mistake are serious, verify with a dedicated forensic metadata tool rather than relying on any single check.

Checking a file before you send it

You do not have to take any tool’s word for this, including ours. Both the tagged source and the prepared output are downloadable below, and the simplest verification needs no software at all: check the reported dimensions. A file whose width and height have swapped relative to the source has had its pixels rotated, not merely its tag altered.

For metadata, most operating systems expose some of it through the file’s properties or information panel — typically the capture date, camera, and, where present, a location. That is enough to confirm the obvious cases. It is not exhaustive, because these panels show a curated subset rather than every field in the file.

The habit worth building is narrower than it sounds: before sending a photograph to anyone outside your immediate circle, prepare a copy rather than attaching the original. The check then becomes unnecessary, because the derivative was built without the metadata in the first place.

Use an original and a prepared copy for different jobs

Keep the original photo when its capture data, colour information, or highest-quality source matters. A prepared output is intentionally a new derivative: it prioritises a normalised orientation, chosen format, optional size and dimension rules, and the omission of copied EXIF/GPS data.

For an upload form, first read its requirements. If it only needs a compatible upright image, prepare one file and inspect it before processing a whole batch. For archival work, retain the original separately and label the prepared copy so nobody mistakes it for the camera master.

The cases where you should keep metadata deserve naming, because stripping is not automatically virtuous. Photographers rely on capture settings to learn from their own work. Embedded copyright and attribution fields are part of a professional deliverable. Evidentiary photographs — an insurance claim, a site survey, a compliance record — are weakened by having their provenance removed. In all of those, strip the copy you share and leave the master intact.

When it still arrives wrong

A prepared file can occasionally still display incorrectly, and the cause is usually downstream rather than in the file. Messaging applications and some social platforms re-encode images on receipt, and a re-encode can reintroduce an orientation tag or apply its own transformation.

The mitigation is to send the file in a way that avoids re-encoding — as a document or attachment rather than as an inline chat image, or through a transfer method that moves the bytes unchanged. This also preserves the quality you chose, which inline sharing frequently does not.

If a recipient reports a sideways image from a prepared file, ask how they received it before assuming the preparation failed. The dimensions in the downloaded file settle the question immediately: if they read 420×640, the file left here upright.