Images & photos · Image Metadata Privacy Tool
How GPS Coordinates Are Stored in EXIF: Rationals, Refs and Precision
· Background
exif image-privacy file-formats
The GPS IFD stores position as three rational numbers each for latitude and longitude, with separate reference tags for hemisphere, plus altitude, a UTC time and optional heading and accuracy fields. Understanding the encoding shows just how precise a geotag is.
The coordinate that was not a decimal — why raw EXIF GPS values look like fractions and letters rather than a map pin
Raw EXIF coordinates do not begin as one decimal map pin. Latitude and longitude are stored as numeric components with separate hemisphere references, so a report must combine fields before a signed value appears. ToolAcre performs that conversion locally and prints the numbers without loading a map tile that would disclose the position to another provider.
The GPS IFD fields this parser recognises
The GPS IFD is reached through a pointer in IFD0 and has its own tag dictionary. The workbook estimated how many fields the wider format may define, but the reliable scope is the implementation table: version, coordinates, altitude, time, satellites, measurement mode, dilution, speed, direction, processing method and date are among the recognised names.
Latitude and longitude as degrees, minutes, seconds — three rationals each, and the N/S and E/W reference tags that give them sign
Latitude and longitude arrive as rational values representing degrees, minutes and seconds, with N, S, E or W stored separately. The conversion takes the absolute degrees plus minutes divided by sixty plus seconds divided by three thousand six hundred, then negates southern and western values. Both coordinate fields must parse before the highlighted decimal pair is shown.
Altitude, time and date — GPSAltitude with its above- or below-sea-level flag, and the GPS timestamp that is always in UTC
Altitude has a reference and value, while GPSTimeStamp and GPSDateStamp provide time-related location fields. The parser displays supplied values but does not authenticate their source or reconcile them with DateTimeOriginal. Every GPS-directory field is treated as sensitive location data, even when its tag is unknown to the dictionary.
Heading, speed and measurement fields
Speed and image direction can describe movement and where the camera faced. GPSDOP and measurement fields may describe the recorded fix, but this tool does not turn them into an accuracy estimate. The correction avoids promising an accuracy tag the implementation does not interpret; formatting precision is not evidence of real-world measurement quality.
Worked example: converting one photo's tags to a decimal coordinate — the arithmetic, and why even a modest fraction identifies a building
For 51 degrees, 30 minutes and 0 seconds north, the formula yields 51.5. For 0 degrees, 7 minutes and 30 seconds west, it yields negative 0.125. The tests verify those calculations and an end-to-end coordinate pair. Use the displayed decimal for awareness, not as proof that the metadata is truthful or current.
What this does not cover — location stored in XMP or in proprietary MakerNote fields, and how map apps geocode the result
Location may also exist in XMP that this viewer does not parse, and MakerNote internals remain opaque. A file can carry GPSDateStamp or direction without a complete coordinate pair, so absence of the highlighted decimal line is not absence of location metadata. Unsupported HEIC, RAW and other containers are rejected rather than interpreted.
Takeaway: precision is the point — the Image Metadata Privacy Tool shows the GPS entries and removes them before you share
Precision is the privacy point, but state only what the file and parser establish. Inspect every GPS entry, not just the map-like pair, and remove the complete EXIF block when sharing does not require those records. The same operation also removes camera and timestamp fields, keeps compressed image data unchanged and leaves the private original on your device.