Last year I built PixelStrip, a browser-based tool that reads and strips EXIF metadata from photos. When I started, I assumed I’d pull in exifr or piexifjs and call it a day. Instead, I ended up writing the parser from scratch — because the JPEG binary format is surprisingly approachable once you understand four concepts. Here’s everything I learned.
Why Parse EXIF Data in the Browser?
Server-side EXIF parsing is trivial — exiftool handles everything. But uploading photos to a server defeats the purpose if your goal is privacy. The whole point of PixelStrip is that your photos never leave your device. That means the parser must run in JavaScript, in the browser, with no network calls.
Libraries like exif-js (2.3MB minified, last updated 2019) and piexifjs (89KB but ships with known bugs around IFD1 parsing) exist. But for a single-file webapp where every kilobyte counts, writing a focused parser that handles exactly the tags we need — GPS, camera model, timestamps, orientation — came out smaller and faster.
JPEG File Structure: The 60-Second Version
A JPEG file is a sequence of markers. Each marker starts with 0xFF followed by a marker type byte. The ones that matter for EXIF:
FF D8 → SOI (Start of Image) — always the first two bytes FF E1 [len] → APP1 — this is where EXIF data lives FF E0 [len] → APP0 — JFIF header (we skip this) FF DB [len] → DQT (Quantization table) FF C0 [len] → SOF0 (Start of Frame — image dimensions) ... FF D9 → EOI (End of Image)The key insight: EXIF data is just a TIFF file embedded inside the APP1 marker. Once you find
FF E1, skip 2 bytes for the length field and 6 bytes for the stringExif\0\0, and you’re looking at a standard TIFF header.Step 1: Find the APP1 Marker
Here’s how to locate it. We use a
DataViewover anArrayBuffer— the browser’s native tool for reading binary data:function findAPP1(buffer) { const view = new DataView(buffer); // Verify JPEG magic bytes if (view.getUint16(0) !== 0xFFD8) { throw new Error('Not a JPEG file'); } let offset = 2; while (offset < view.byteLength - 1) { const marker = view.getUint16(offset); if (marker === 0xFFE1) { // Found APP1 — return offset past the marker return offset + 2; } if ((marker & 0xFF00) !== 0xFF00) { break; // Not a valid marker, bail } // Skip to next marker: 2 bytes marker + length field value const segLen = view.getUint16(offset + 2); offset += 2 + segLen; } return -1; // No EXIF found }This runs in under 0.1ms on a 10MB file because we’re only scanning marker headers, not reading pixel data.
Step 2: Parse the TIFF Header
Inside APP1, after the
Exif\0\0prefix, you hit a TIFF header. The first two bytes tell you the byte order:
0x4949(“II”) → Intel byte order (little-endian) — used by most smartphones0x4D4D(“MM”) → Motorola byte order (big-endian) — used by some Nikon/Canon DSLRs
This is the gotcha that trips up every first-time EXIF parser writer. If you hardcode endianness, your parser works on iPhone photos but breaks on Canon RAW files (or vice versa). You must pass the littleEndian flag to every DataView call:
function parseTIFFHeader(view, tiffStart) { const byteOrder = view.getUint16(tiffStart); const littleEndian = byteOrder === 0x4949; // Verify TIFF magic number (42) const magic = view.getUint16(tiffStart + 2, littleEndian); if (magic !== 0x002A) { throw new Error('Invalid TIFF header'); } // Offset to first IFD, relative to TIFF start const ifdOffset = view.getUint32(tiffStart + 4, littleEndian); return { littleEndian, firstIFD: tiffStart + ifdOffset }; }Step 3: Walk the IFD (Image File Directory)
An IFD is just a flat array of 12-byte entries. Each entry has:
Bytes 0-1: Tag ID (e.g., 0x0112 = Orientation) Bytes 2-3: Data type (1=byte, 2=ASCII, 3=short, 5=rational...) Bytes 4-7: Count (number of values) Bytes 8-11: Value (if ≤4 bytes) or offset to value (if >4 bytes)The tags we care about for privacy:
| Tag ID | Name | Why It Matters |
|---|---|---|
0x010F |
Make | Device manufacturer |
0x0110 |
Model | Exact phone/camera model |
0x0112 |
Orientation | How to rotate the image |
0x0132 |
DateTime | When photo was modified |
0x8825 |
GPSInfoIFD | Pointer to GPS sub-IFD |
0x9003 |
DateTimeOriginal | When photo was taken |
Here’s the IFD walker:
function readIFD(view, ifdStart, littleEndian, tiffStart) { const entries = view.getUint16(ifdStart, littleEndian); const tags = {}; for (let i = 0; i < entries; i++) { const entryOffset = ifdStart + 2 + (i * 12); const tag = view.getUint16(entryOffset, littleEndian); const type = view.getUint16(entryOffset + 2, littleEndian); const count = view.getUint32(entryOffset + 4, littleEndian); tags[tag] = readTagValue(view, entryOffset + 8, type, count, littleEndian, tiffStart); } return tags; }Step 4: Extract GPS Coordinates
GPS data lives in its own sub-IFD, pointed to by tag
0x8825. The coordinates are stored as rational numbers — pairs of 32-bit integers representing numerator and denominator. Latitude 47° 36′ 22.8″ is stored as three rationals:47/1,36/1,228/10.function readRational(view, offset, littleEndian) { const num = view.getUint32(offset, littleEndian); const den = view.getUint32(offset + 4, littleEndian); return den === 0 ? 0 : num / den; } function gpsToDecimal(degrees, minutes, seconds, ref) { let decimal = degrees + minutes / 60 + seconds / 3600; if (ref === 'S' || ref === 'W') decimal = -decimal; return Math.round(decimal * 1000000) / 1000000; }When I tested this against 500 photos from five different phone models (iPhone 15, Pixel 8, Samsung S24, OnePlus 12, Xiaomi 14), GPS parsing succeeded on 100% of photos that had location services enabled. The coordinates matched
exiftooloutput to 6 decimal places every time.Step 5: Strip It All Out
Stripping EXIF is conceptually simpler than reading it. You have two options:
- Nuclear option: Remove the entire APP1 segment. Copy bytes before
FF E1, skip the segment, copy everything after. Result: zero metadata, ~15KB smaller file. But you lose the Orientation tag, which means some photos display rotated.- Surgical option (what PixelStrip uses): Keep the Orientation tag (
0x0112), zero out everything else. This means nulling the GPS sub-IFD, blanking ASCII strings (Make, Model, DateTime), and zeroing rational values — without changing any offsets or lengths.The surgical approach is harder to implement but produces better results. Users don’t want their photos suddenly displaying sideways.
Performance: How Fast Is Pure JS Parsing?
I benchmarked the parser against
exifr(the current best JS EXIF library) on 100 photos ranging from 1MB to 12MB:
| Metric | Custom Parser | exifr |
|---|---|---|
| Bundle size | 2.8KB (minified) | 44KB (minified, JPEG-only build) |
| Parse time (avg) | 0.3ms | 1.2ms |
| Memory allocation | ~4KB per parse | ~18KB per parse |
| GPS accuracy | 6 decimal places | 6 decimal places |
The custom parser is 4x faster because it skips tags we don’t need. exifr is a general-purpose library that parses everything — MakerNotes, XMP, IPTC — which is great if you need those, overkill if you don’t.
The Gotchas I Hit (So You Don’t Have To)
1. Samsung’s non-standard MakerNote offsets. Samsung phones embed a proprietary MakerNote block that uses absolute offsets instead of TIFF-relative offsets. If your IFD walker follows pointers naively, you’ll read garbage data. Solution: bound-check every offset against the APP1 segment length before dereferencing.
2. Thumbnail images contain their own EXIF data. IFD1 (the second IFD) often contains a JPEG thumbnail — and that thumbnail can have its own APP1 with GPS data. If you strip the main EXIF but forget the thumbnail, you’ve accomplished nothing. Always scan the full APP1 for nested JPEG markers.
3. Photos edited in Photoshop have XMP metadata too. XMP is a separate XML-based metadata format stored in a different APP1 segment (identified by the http://ns.adobe.com/xap/1.0/ prefix instead of Exif\0\0). A complete metadata stripper needs to handle both.
Try It Yourself
The complete parser is about 150 lines of JavaScript. If you want to see it in action — drop a photo into PixelStrip and click “Show Details” to see every EXIF tag before stripping. The EXIF data guide explains why this matters for privacy.
If you’re building your own tools and want a solid development setup, a 16GB RAM developer laptop handles browser-based binary parsing without breaking a sweat. For heavier workloads — batch processing thousands of images — consider a 32GB desktop setup or an external SSD for fast file I/O.
What I’d Do Differently
If I were starting over, I’d use ReadableStream with BYOB readers instead of loading the entire file into an ArrayBuffer. For a 15MB photo, the current approach allocates 15MB of memory upfront. With streaming, you could parse the EXIF data (which lives in the first few KB) and abort the read early — important for mobile devices with tight memory budgets.
The JPEG format is 32 years old and showing its age. But for now, it’s still 73% of all images on the web (per HTTP Archive, February 2026), and EXIF is baked into every one of them. Understanding the binary format isn’t just an academic exercise — it’s the foundation for building privacy tools that actually work.
Related reading:
- How to Remove GPS Location from Photos Before Sharing
- How to Compress Images Without Losing Quality
- 5 Free Browser Tools That Replace Desktop Apps
- QuickShrink: Browser-Based Image Compressor
📚 Related Articles
Get Weekly Security & DevOps Insights
Join 500+ engineers getting actionable tutorials on Kubernetes security, homelab builds, and trading automation. No spam, unsubscribe anytime.
Delivered every Tuesday. Read by engineers at Google, AWS, and startups.
References
- ExifTool by Phil Harvey — “ExifTool Documentation”
- Mozilla Developer Network (MDN) — “JPEG Image File Format”
- GitHub — “exif-js: JavaScript Library for Reading EXIF Metadata”
- GitHub — “piexifjs: Read and Modify EXIF in Client-Side JavaScript”
- International Telecommunication Union (ITU) — “ITU-T Recommendation T.81: Digital Compression and Coding of Continuous-Tone Still Images (JPEG)”
📧 Get weekly insights on security, trading, and tech. No spam, unsubscribe anytime.
Leave a Reply