Images & photos · Image Metadata Privacy Tool
How a Browser Reads EXIF From a JPEG Without Uploading It
· How it works
exif image-privacy browser-processing file-formats
A walkthrough of what actually happens between dropping a JPEG on the page and seeing its metadata: the bytes are read locally, the APP1 segment is located, and the TIFF directories inside it are decoded in JavaScript, with no server involved.
The claim to test: 'nothing is uploaded' — why a metadata inspector only needs to read bytes it already has, and how to confirm no request leaves the tab
The claim that a photograph is not uploaded is testable rather than decorative. The tool reads the selected File into an ArrayBuffer, converts it to bytes and passes those bytes directly to the metadata reader. Its privacy statement limits the promise carefully: the photograph is parsed in the browser tab, no copy is stored, and disclosed analytics requests are separate from the code path that handles the file.
Reading the file locally with the File API — how the browser hands the tool an ArrayBuffer of your photo without the bytes leaving the device
A file picker supplies a browser File object, and file.arrayBuffer() makes its contents available to JavaScript already running in the page. ToolAcre enforces a 50 MB ceiling, then identifies JPEG, PNG or WebP from the bytes themselves. This local read does not need a form submission or an image-upload endpoint, and the network-isolation test exercises all three supported formats without recording a request.
Finding the APP1 segment — walking JPEG markers from SOI to the 'Exif' header, and skipping segments that carry ICC or XMP instead
For JPEG, the reader starts after the start-of-image marker and walks marker segments until the start-of-scan marker. It recognises APP1 payloads beginning with Exif and parses those, while XMP is detected only for removal and ICC is deliberately retained as rendering data. Everything from the scan marker onward belongs to the compressed picture path rather than the EXIF report.
Decoding the TIFF header and IFDs — byte order (II or MM), the offset to IFD0, and the 12-byte entries that point to the Exif and GPS sub-directories
An EXIF payload contains a TIFF block. The parser reads the II or MM byte-order marker, checks the TIFF magic value and follows the offset to IFD0. Each directory entry supplies a tag, type, count and either an inline value or an offset. From IFD0 the code follows only the Exif and GPS sub-directory pointers, keeping the traversal bounded instead of chasing every possible private structure.
Turning raw tag values into readable fields — tag IDs, data types, rationals and ASCII strings, and why some values need a lookup table
Raw values become useful only after their types and tags are interpreted. ASCII fields become strings, numeric types use the TIFF byte order, and rational pairs become numbers after numerator and denominator are read. A tag dictionary labels camera make, model, timestamps, software, serial fields and GPS values, then classifies location and device identity ahead of less sensitive technical fields.
Worked example: a phone photo parsed on the main thread
The workbook described this example as running in a Web Worker, but the shipped panel calls readMetadata directly after awaiting file.arrayBuffer(); no worker participates in this path. A selected phone JPEG is therefore read and parsed on the page main thread, after which any latitude and longitude are printed as numbers and the full field table is rendered. The correction matters because local processing and worker processing are different claims.
What this does not cover — MakerNote internals, RAW formats, HEIC and video containers are outside this walkthrough and outside the tool
The reader is intentionally incomplete. It does not decode MakerNote internals, IFD1 thumbnail fields, JPEG XMP contents or unsupported RAW, HEIC, AVIF, TIFF, GIF and SVG containers. A corrupt EXIF segment is skipped so it cannot block later removal. An empty report means only that this bounded parser found no readable fields, not that every possible information channel is absent.
Takeaway: reading metadata is a local, byte-level job — the Image Metadata Privacy Tool does exactly this, so you can inspect before you share without trusting a server
Reading metadata is a local byte-level job when the implementation keeps the selected bytes in the tab and performs no request with them. Use the report to identify what this parser can see, then use the separate removal action when a cleaned copy is needed. Inspection never changes the original photograph, and the source code and network-isolation test provide stronger evidence than a generic browser-processing badge.