How to Strip EXIF & GPS Metadata from Images in the Browser Without Quality Loss

Hicham Elkhatir — Tue, 03 Nov 2026 14:45:44 +0000

When users want to remove GPS coordinates, camera serial numbers, timestamps, and other private metadata from photos before uploading them to the web, the most common advice is:

"Just load the image into a canvas and export it again."

It sounds simple. But there's a problem: you're decoding and re-encoding the entire image just to remove a few metadata bytes.

Here's what that approach typically looks like in JavaScript:

// The traditional approach: decode and re-encode pixels
const img = new Image();
img.src = URL.createObjectURL(file);
await img.decode();

const canvas = document.createElement('canvas');
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;

const ctx = canvas.getContext('2d');
ctx.drawImage(img, 0, 0);

// Re-encoding introduces potential quality loss
canvas.toBlob((blob) => {
  download(blob);
}, 'image/jpeg', 0.92);

This works, but it's an unnecessarily expensive operation for a metadata-removal task.

Why Canvas Re-Encoding Isn't Ideal

There are four main problems with this approach.

1. Generational Quality Loss

JPEG uses lossy compression based on the discrete cosine transform (DCT) and quantization.

When an already-compressed JPEG is decoded and exported again, another lossy compression cycle occurs. This can introduce additional artifacts, edge ringing, and color degradation.

2. Color Profile Changes

Canvas exports don't necessarily preserve the original ICC color profile.

For images captured in wide-gamut color spaces such as Display P3, this can result in color differences depending on the browser and export pipeline.

3. High Memory Consumption

A 48-megapixel image decoded into an RGBA pixel buffer requires approximately 192 MB of memory for the pixel data alone.

That's before accounting for the original file, canvas backing storage, and other browser overhead.

On mobile devices, this can become a serious performance issue.

4. Privacy Concerns

Many online EXIF removal services process images on remote servers.

If someone is removing GPS coordinates because they don't want to expose their home address, uploading that same image to an unknown server defeats much of the privacy benefit.

The Alternative: Byte-Level Binary Parsing

While building the client-side privacy tools for ImgToolZone, we explored a different approach.

Instead of decoding the image into pixels, we treat it as what it actually is: a binary container.

Using JavaScript's Uint8Array, we can inspect the image structure, identify metadata segments, and remove only the parts we don't need.

No canvas. No pixel decoding. No image re-encoding.

Understanding JPEG Structure

A JPEG file is organized into segments identified by markers, most of which begin with the byte 0xFF.

Here's a simplified overview of the important markers:

Marker	Name	Description	Action
`0xFFD8`	SOI	Start of Image	Preserve
`0xFFE0`	APP0	JFIF Header	Preserve
`0xFFE1`	APP1	EXIF / XMP	Remove
`0xFFE2`	APP2	ICC Profile	Preserve
`0xFFED`	APP13	Photoshop / IPTC	Remove
`0xFFDB`	DQT	Quantization Table	Preserve
`0xFFC0`	SOF0	Frame Header	Preserve
`0xFFDA`	SOS	Start of Scan	Preserve
`0xFFD9`	EOI	End of Image	Preserve

The important part is that the compressed image data remains untouched.

We simply remove selected metadata segments while copying the remaining bytes into a new output buffer.

This means the JPEG's compressed image data is preserved without another lossy compression cycle.

The Code: A Basic Client-Side JPEG Metadata Stripper

Here's a simplified implementation demonstrating the concept:

export function stripJpegMetadata(bytes) {
  // Verify JPEG SOI marker
  if (
    bytes.length < 4 ||
    bytes[0] !== 0xFF ||
    bytes[1] !== 0xD8
  ) {
    throw new Error('Invalid JPEG file');
  }

  const chunks = [
    new Uint8Array([0xFF, 0xD8])
  ];

  let offset = 2;
  const len = bytes.length;

  while (offset < len) {
    if (bytes[offset] !== 0xFF) {
      throw new Error('Invalid JPEG marker');
    }

    const marker = bytes[offset + 1];

    // End of Image
    if (marker === 0xD9) {
      chunks.push(bytes.subarray(offset, offset + 2));
      break;
    }

    // Start of Scan: preserve the remaining compressed data
    if (marker === 0xDA) {
      chunks.push(bytes.subarray(offset));
      break;
    }

    // Validate segment length
    if (offset + 4 > len) {
      throw new Error('Truncated JPEG segment');
    }

    const segmentLength =
      (bytes[offset + 2] << 8) |
      bytes[offset + 3];

    const segmentEnd = offset + 2 + segmentLength;

    if (
      segmentLength < 2 ||
      segmentEnd > len
    ) {
      throw new Error('Invalid JPEG segment length');
    }

    // Metadata segments to remove
    const isMetadata =
      marker === 0xE1 || // APP1: EXIF / XMP
      marker === 0xED || // APP13: IPTC / Photoshop
      marker === 0xFE;   // COM: Comments

    if (!isMetadata) {
      chunks.push(bytes.subarray(offset, segmentEnd));
    }

    offset = segmentEnd;
  }

  // Calculate output size
  const totalLength = chunks.reduce(
    (total, chunk) => total + chunk.length,
    0
  );

  // Build sanitized JPEG
  const result = new Uint8Array(totalLength);

  let position = 0;

  for (const chunk of chunks) {
    result.set(chunk, position);
    position += chunk.length;
  }

  return result;
}

Important: This is an educational implementation of the basic JPEG marker-parsing approach, not a complete production-ready JPEG sanitizer. Production implementations should handle standalone markers, multiple scans, marker fill bytes, malformed files, and metadata that may appear in different locations. They should also validate the final output.

What About PNG and WebP?

The same general principle applies to other image formats, although their container structures are different.

PNG

PNG files consist of chunks containing a length, type, data, and CRC.

We can remove metadata-related chunks such as:

eXIf
tEXt
zTXt
iTXt

While preserving essential image chunks such as:

IHDR
PLTE
IDAT
IEND

A production implementation should also recalculate chunk CRCs where required.

WebP

WebP uses the RIFF container format.

Its chunks are identified using FourCC identifiers. We can inspect these chunks and remove EXIF and XMP metadata while preserving the actual image data stored in VP8 or VP8L chunks.

The key idea remains the same: modify the container without decoding and re-encoding the image.

Performance: Why Avoid Decoding Pixels?

Consider a 12 MB smartphone photograph.

A byte-level approach avoids allocating a massive uncompressed RGBA pixel buffer just to remove metadata.

Here's an illustrative comparison:

Metric	Canvas Re-Encoding	Byte-Level Parsing
Pixel decoding	Required	Not required
Pixel re-encoding	Required	Not required
Original JPEG bitstream	Replaced	Preserved
Additional pixel buffer	Required	Not required
ICC profile	May change	Can be preserved
Processing overhead	Higher	Generally lower

Actual execution times and memory consumption depend on the browser, device, image dimensions, and implementation. Benchmarking both approaches on the same hardware is necessary before publishing specific performance numbers.

Putting It Into Practice

We implemented this approach as part of the privacy-focused image tools available on ImgToolZone.

You can try the tools here:

EXIF Remover: Remove image metadata while preserving the original compressed image data.
EXIF Viewer: Inspect embedded metadata, including GPS information and camera details.

Everything runs directly in your browser using JavaScript.

No account required. No server uploads. No watermarks.

Final Thoughts

Sometimes the best optimization isn't making an existing process faster. It's realizing that you don't need to perform that process in the first place.

If your goal is simply to remove metadata, decoding millions of pixels and compressing them again is often unnecessary.

By understanding the underlying binary structure of image formats, we can build faster, more privacy-friendly tools while preserving the original compressed image data.

Have you used byte-level parsing for image processing in your projects? I'd be interested to hear how you handle metadata across different image formats.

DEV Community: Hicham Elkhatir