Blog

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 string Exif\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 DataView over an ArrayBuffer — 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\0 prefix, you hit a TIFF header. The first two bytes tell you the byte order:

• 0x4949 (“II”) → Intel byte order (little-endian) — used by most smartphones
• 0x4D4D (“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:

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 exiftool output to 6 decimal places every time.

Step 5: Strip It All Out

Stripping EXIF is conceptually simpler than reading it. You have two options:

1. 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.
2. 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:

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

I ran the same 10 images through five different online compressors and measured everything: output file size, visual quality loss, compression speed, and what happened to my data. Two of the five uploaded my photos to servers in jurisdictions I couldn’t identify. One silently downscaled my images. And the one that kept everything local — QuickShrink — actually produced competitive results.

Here’s the full breakdown.

The Test Setup

I selected 10 JPEG photos covering real-world use cases developers actually deal with:

• Product shots (3 images) — white background e-commerce photos, 3000×3000px, 4-6MB each
• Screenshots (3 images) — IDE and terminal captures, 2560×1440px, 1-3MB each
• Photography (2 images) — landscape shots from a Pixel 8, 4000×3000px, 5-8MB each
• UI mockups (2 images) — Figma exports with gradients and text, 1920×1080px, 2-4MB each

Total input: 10 files, 38.7MB combined. Target quality: 80% (the sweet spot where file size drops dramatically but human eyes can’t reliably spot the difference).

The five compressors tested:

1. TinyPNG — the default most developers reach for
2. Squoosh — Google’s open-source option (squoosh.app)
3. Compressor.io — popular alternative with multiple format support
4. iLoveIMG — widely recommended in “best tools” roundups
5. QuickShrink — our browser-only compressor at tools.orthogonal.info/quickshrink

File Size Results: Who Actually Compresses Best?

Here’s where it gets interesting. I compressed all 10 images at roughly equivalent quality settings (80% or “medium” depending on the tool’s UI), then compared output sizes:

Average compression ratio (smaller = better):

• TinyPNG: 72.4% reduction (38.7MB → 10.7MB)
• Squoosh (MozJPEG): 74.1% reduction (38.7MB → 10.0MB)
• Compressor.io: 68.9% reduction (38.7MB → 12.0MB)
• iLoveIMG: 61.3% reduction (38.7MB → 15.0MB)*
• QuickShrink: 70.2% reduction (38.7MB → 11.5MB)

*iLoveIMG’s “medium” setting is more conservative than the others. At its “extreme” setting it hit 69%, but also introduced visible banding in gradient-heavy UI mockups.

Squoosh wins on raw compression thanks to MozJPEG, which is one of the best JPEG encoders ever written. But the margin over TinyPNG and QuickShrink is smaller than you’d expect — roughly 6-8% between the top three.

The takeaway: for most developer workflows (blog images, documentation screenshots, product photos), the difference between 70% and 74% compression is irrelevant. You’re saving maybe 200KB per image. What matters more is everything else.

Speed: Canvas API vs Server-Side Processing

This is where architectures diverge. TinyPNG, Compressor.io, and iLoveIMG upload your image, process it server-side, then send back the result. Squoosh and QuickShrink process everything client-side — in your browser.

Average time per image (including upload/download where applicable):

• TinyPNG: 3.2 seconds (upload 1.8s + processing 0.9s + download 0.5s)
• Squoosh: 1.4 seconds (local WebAssembly processing)
• Compressor.io: 4.1 seconds (slower uploads, larger queue)
• iLoveIMG: 2.8 seconds (fast CDN)
• QuickShrink: 0.8 seconds (Canvas API, no network)

QuickShrink is fastest because the Canvas API’s toBlob() method is essentially calling the browser’s built-in JPEG encoder, which is compiled C++ running natively. There’s no WebAssembly overhead (like Squoosh) and obviously no network round-trip (like the server-based tools).

Here’s what the core compression looks like under the hood:

// The heart of browser-based compression
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
ctx.drawImage(img, 0, 0);

// This single call does all the heavy lifting
canvas.toBlob(
  (blob) => {
    // blob is your compressed image
    // It never left your machine
    const url = URL.createObjectURL(blob);
    downloadLink.href = url;
  },
  'image/jpeg',
  0.80 // quality: 0.0 to 1.0
);

That’s it. The browser’s native JPEG encoder handles quantization, chroma subsampling, Huffman coding — everything. No library, no dependency, no server. The Canvas API has been stable across all major browsers since 2015.

The Privacy Test: Where Do Your Photos Go?

This is the part that should bother you. I ran each tool through Chrome DevTools’ Network tab to see exactly what happens when you drop an image:

• TinyPNG: Uploads to api.tinify.com (Netherlands). Image stored temporarily. Privacy policy says files are deleted after some hours. You’re trusting their word.
• Squoosh: ✅ 100% client-side. Zero network requests during compression. Service worker caches the app for offline use.
• Compressor.io: Uploads to their servers. I watched a 6MB photo leave my browser. Their privacy page is one paragraph.
• iLoveIMG: Uploads to api3.ilovepdf.com. Files “deleted after 2 hours.” Servers appear to be in Spain (EU GDPR applies, which is good).
• QuickShrink: ✅ 100% client-side. Zero network requests. Works fully offline once loaded. I tested by enabling airplane mode — still works.

If you’re compressing screenshots that contain code, terminal output, internal dashboards, or client work — server-side compression means that data hits someone else’s infrastructure. For a personal photo, maybe you don’t care. For a screenshot of your production database? You should care a lot.

The Hidden Gotcha: Silent Downscaling

I noticed something odd with iLoveIMG. My 4000×3000px landscape photo came back at 2000×1500px. The file was smaller, sure — but not because of better compression. It was because they halved the dimensions without telling me.

I double-checked: there was no “resize” option enabled. Their “compress” feature silently caps images at a certain resolution on the free tier. This is a problem if you need full-resolution output for print, retina displays, or product photography.

None of the other four tools altered image dimensions.

When to Use What: My Honest Recommendation

Use Squoosh when you need maximum compression and don’t mind a slightly more complex UI. The MozJPEG encoder is genuinely better than browser-native JPEG, and it supports WebP, AVIF, and other modern formats. It’s the technically superior tool.

Use QuickShrink when you want the fastest possible workflow: drop image, download compressed version, done. No format decisions, no sliders, no settings panels. The Canvas API approach trades 3-4% compression efficiency for massive speed gains and zero complexity. I use it daily for blog images and documentation screenshots — exactly the use case where “good enough compression, instantly” beats “perfect compression, eventually.”

Use TinyPNG when you’re batch-processing hundreds of images through their API and don’t have privacy constraints. Their WordPress plugin and CLI tools are well-maintained. At $0.009/image after the free 500, it’s cheap automation.

Skip iLoveIMG unless you specifically need their PDF tools. The silent downscaling and middling compression don’t justify using a server-side tool when better client-side options exist.

Skip Compressor.io — Squoosh does everything it does, client-side, with better compression.

The Broader Point: Why Client-Side Tools Win

The web platform in 2026 is absurdly capable. The Canvas API, WebAssembly, the File API, Service Workers — you can build tools that rival desktop apps without a single server-side dependency. And when your tool runs entirely in the user’s browser:

• No hosting costs — static files on a CDN, done
• No privacy liability — you never touch user data
• No scaling problems — every user brings their own compute
• Offline capable — works on planes, in cafes with bad wifi, wherever

This is why I build browser-only tools. Not because client-side compression is always technically best — Squoosh’s MozJPEG proves server-grade encoders can run client-side too via WASM. But because the combination of speed, privacy, and simplicity makes it the right default for 90% of developer workflows.

Try QuickShrink with your own images and see the numbers yourself. And if metadata privacy matters too, run those same photos through PixelStrip — it strips EXIF, GPS, and camera data the same way: entirely in your browser, with nothing uploaded anywhere. For managing code snippets without yet another Electron app, check out TypeFast.

Tools for Your Developer Setup

If you’re optimizing your development workflow, the right hardware makes a difference. A high-resolution monitor helps when comparing compression artifacts side-by-side (I use a 4K display and it’s the first upgrade I’d recommend). For photography workflows, a fast SD card reader eliminates the bottleneck of transferring images from camera to computer. And if you’re processing images in bulk for a client project, a portable SSD keeps your originals safe while you experiment with compression settings — never compress your only copy.

The Pomodoro Technique — work for 25 minutes, break for 5 — has been around since 1987. The science backs it up: time-boxing reduces procrastination and improves focus. But here’s the problem: most people try it for three days and quit. Not because the technique fails, but because a plain countdown timer gives you zero reason to come back tomorrow.

Why Streaks Change Everything

Duolingo built a $12 billion company on one psychological trick: the daily streak. Miss a day and your streak resets to zero. It sounds trivial. It works because loss aversion is 2x stronger than the desire for gain (Kahneman & Tversky, 1979). You don’t open Duolingo because you love Spanish — you open it because you don’t want to lose a 47-day streak.

The same psychology applies to focus timers. A countdown from 25:00 gives you no stakes. A countdown that says “Day 23 of your focus streak” gives you skin in the game.

How FocusForge Applies This

FocusForge adds three layers to the basic Pomodoro timer:

• XP — every completed session earns experience points (25 XP for a Quick session, 75 XP for a Marathon)
• Levels — Rookie → Apprentice → Expert → Master → Legend → Immortal. Each level has its own badge.
• Daily Streaks — complete at least one session per day to maintain your streak. Miss a day, restart from zero.

The actual Pomodoro technique is unchanged. You still focus for 25 minutes (or 45 or 60). But now there’s a reason to do it consistently.

👉 Try FocusForge on Google Play — free with optional $1.99 upgrade to remove ads.

Related Reading

Want to know more about FocusForge’s design and gamification mechanics? Read the full deep-dive: FocusForge: How Gamification Tricked Me Into Actually Using a Pomodoro Timer. FocusForge is part of our suite of 5 free browser tools that replace desktop apps — including NoiseLog, a sound meter app for documenting noise complaints.