DEV Community: Ishan IND

Parsing and Stripping EXIF Metadata Completely In-Browser with JavaScript ArrayBuffers

Ishan IND — Sun, 25 Oct 2026 08:01:37 +0000

Every smartphone photo you take embeds precise metadata inside the file: GPS latitude and longitude, camera serial numbers, lens focal lengths, and timestamps. When users look for an online tool to check or clean this data before sharing an image, 95% of web utilities ask them to upload their private photo to an external backend server.

From a privacy standpoint, uploading a sensitive photo to a remote server just to strip a few kilobytes of metadata completely defeats the purpose.

The common frontend alternative—loading the image into an HTML5 <canvas> and calling canvas.toBlob('image/jpeg')—is equally flawed. A canvas re-encodes the image, which introduces compression artifacts, alters the color profile, and blows away the original image quality.

While engineering ScanMetadata, we designed the parser and scrubber to run 100% client-side directly in the browser's memory using ArrayBuffer and DataView. Here is how JPEG binary markers work and how to strip EXIF data losslessly without touching a single pixel.

1. Anatomy of a JPEG: Where EXIF Actually Lives

A JPEG file is not a continuous block of pixels; it is organized into sequential binary blocks called segments, each starting with a two-byte marker (0xFF followed by a marker code):

0xFFD8 — SOI (Start of Image): The first two bytes of every valid JPEG.
0xFFE1 — APP1 Segment: Where EXIF metadata (camera specs, GPS coordinates, thumbnail) is stored.
0xFFE0 — APP0 Segment: Standard JFIF header.
0xFFDB — DQT: Quantization tables.
0xFFC0 / 0xFFC2 — SOF: Frame header (image width, height, bit depth).
0xFFDA — SOS (Start of Scan): The beginning of the actual compressed image payload.
0xFFD9 — EOI (End of Image): The trailing two bytes marking the file termination.

Immediately following any segment marker (except SOI, EOI, and SOS), the next two bytes represent the length of that entire segment (including those two length bytes themselves, stored in Big-Endian format).

2. Reading Binary Markers with DataView

To inspect metadata safely without reading entire multi-megabyte files at once, we use the File API with a FileReader or file.arrayBuffer() slice and inspect it through a DataView:

export async function locateExifSegment(file) {
  // Read only the first 128KB to locate headers quickly
  const slice = await file.slice(0, 131072).arrayBuffer();
  const view = new DataView(slice);

  // Validate SOI Marker (0xFFD8)
  if (view.getUint16(0, false) !== 0xffd8) {
    throw new Error("Invalid JPEG: Missing SOI marker");
  }

  let offset = 2;
  const length = view.byteLength;

  while (offset < length - 4) {
    const marker = view.getUint16(offset, false);

    // Stop if we hit Start of Scan (SOS) - image data starts here
    if (marker === 0xffda || marker === 0xffd9) {
      break;
    }

    // 0xFFE1 is the APP1 / EXIF Marker
    if (marker === 0xffe1) {
      const segmentLength = view.getUint16(offset + 2, false);
      return {
        hasExif: true,
        startOffset: offset,
        totalLength: segmentLength + 2 // includes the 2-byte marker itself
      };
    }

    // Move to the next segment: marker (2 bytes) + segment length
    const segmentLength = view.getUint16(offset + 2, false);
    offset += 2 + segmentLength;
  }

  return { hasExif: false, startOffset: -1, totalLength: 0 };
}

3. Parsing the TIFF Header and Endianness

Inside the 0xFFE1 segment, the payload starts with the ASCII string "Exif\0\0" (6 bytes), immediately followed by the TIFF header.

The first two bytes of the TIFF header indicate byte alignment (Endianness):

0x4949 ("II"): Intel format (Little-Endian)
0x4D4D ("MM"): Motorola format (Big-Endian)

Reading values with the wrong endianness corrupts the tag pointers and GPS coordinates. Here is how we extract whether the file uses Little-Endian:

export function inspectTiffHeader(view, exifStartOffset) {
  // Offset + 4 bytes (marker + length) + 6 bytes ("Exif\0\0")
  const tiffOffset = exifStartOffset + 10;
  const endianTag = view.getUint16(tiffOffset, false);

  let isLittleEndian;
  if (endianTag === 0x4949) {
    isLittleEndian = true; // Intel
  } else if (endianTag === 0x4d4d) {
    isLittleEndian = false; // Motorola
  } else {
    throw new Error("Invalid TIFF header format");
  }

  // The next 2 bytes must be the constant 42 (0x002A)
  const magic = view.getUint16(tiffOffset + 2, isLittleEndian);
  if (magic !== 42) {
    throw new Error("Malformed TIFF header");
  }

  // First Image File Directory (IFD0) offset
  const ifd0Offset = view.getUint32(tiffOffset + 4, isLittleEndian);
  return { tiffOffset, isLittleEndian, ifd0Offset };
}

4. Lossless Stripping via Buffer Slicing (No Canvas)

Instead of passing the file into an HTML canvas and re-compressing the pixels, we can strip the metadata with zero quality loss by slicing the ArrayBuffer around the 0xFFE1 segment:

export async function stripExifLossless(file) {
  const buffer = await file.arrayBuffer();
  const view = new DataView(buffer);

  // Verify JPEG header
  if (view.getUint16(0, false) !== 0xffd8) {
    return file; // Not a JPEG, return untouched
  }

  const chunks = [];
  let cursor = 0;
  let offset = 2;

  // Add the initial SOI marker
  chunks.push(buffer.slice(0, 2));
  cursor = 2;

  while (offset < buffer.byteLength - 4) {
    const marker = view.getUint16(offset, false);

    // Hit SOS or EOI - copy the remainder of the compressed image
    if (marker === 0xffda || marker === 0xffd9) {
      break;
    }

    const segmentLength = view.getUint16(offset + 2, false);
    const totalSegmentBytes = 2 + segmentLength;

    // If marker is APP1 (EXIF) or APP2 (FlashPix/ICC profiles if desired), omit it
    if (marker === 0xffe1) {
      // Push everything up to this marker
      if (offset > cursor) {
        chunks.push(buffer.slice(cursor, offset));
      }
      // Skip the entire EXIF block without copying
      cursor = offset + totalSegmentBytes;
    }

    offset += totalSegmentBytes;
  }

  // Append all remaining bytes (raw image data through EOI)
  if (cursor < buffer.byteLength) {
    chunks.push(buffer.slice(cursor));
  }

  // Construct a sanitized Blob with original MIME type
  return new Blob(chunks, { type: file.type || "image/jpeg" });
}

Why This Architecture Matters:

100% Lossless: Not a single DCT coefficient or quantization table is re-encoded. The resulting photo is mathematically identical in image quality, just lighter by the size of the removed tags.
Instant Performance: Parsing or removing headers takes 2–5 milliseconds even on 40MB RAW/JPEG smartphone exports because the CPU only slices memory buffers.
Absolute Privacy: User files never leave the browser's JavaScript sandbox. There are no tracking scripts, no database logs, and no S3 buckets.

You can inspect full EXIF payloads, check GPS location tags, and test the zero-upload sanitizer live at ScanMetadata.

The complete source code and binary parsing implementation is open-sourced on GitHub.

Building a Millisecond-Accurate Morse Engine in JavaScript (Syncing 600Hz Web Audio, SVG, and the Camera Torch)

Ishan IND — Sun, 25 Oct 2026 07:50:02 +0000

Most Morse code generators on the web do two things wrong: they render signals as plain periods (.) and hyphens (-)—which completely misrepresents the physical duration of the marks—and they play audio by chaining setTimeout calls.

If you have ever tried building a rhythm-based tool in the browser using setTimeout, you already know what happens. Within four or five words, main-thread jitter and browser timer throttling push the audio out of step with the UI.

While building Morse Universe, I wanted every tool on the site—the translator, the audio/video decoders, the 40-lesson Koch trainer, and the printable charts—to run off a single underlying engine and a single timetable. Whether the browser is playing a 600 Hz tone, lighting up an SVG bar drawn to true 1:3 scale, buzzing the phone's vibration motor, or blinking the rear camera flash on Android Chrome, every output has to stay in step to the millisecond.

Here is how the timing math, the Web Audio lookahead scheduler, and the hardware outputs work under the hood.

1. The Timing Math: ITU-R M.1677-1 and Farnsworth Spacing

International Morse code timing is defined by the ITU-R M.1677-1 standard. Everything is measured in multiples of a single base unit (one dit):

Dit (short mark): 1 unit
Dah (long mark): 3 units
Intra-character gap (between marks of the same letter): 1 unit
Inter-character gap (between letters): 3 units
Word gap: 7 units

To convert Words Per Minute (WPM) into milliseconds, standard telegraphy uses the reference word "PARIS", which takes exactly 50 units (including the trailing word space). At 1 WPM, 50 units take 60,000 ms, which simplifies to:

Unit Duration (ms) = 1200 / WPM

At 20 WPM, a single dit lasts exactly 60 ms, and a dah lasts 180 ms.

Handling Farnsworth Timing

When beginners learn Morse at 5 WPM, they end up counting dots and dashes instead of recognizing the acoustic rhythm of each letter. In 1990, the ARRL adopted Farnsworth timing for code practice: characters are sent at full speed (say, 20 WPM) so their rhythm stays intact, while the gaps between letters and words are stretched by 2x or 3x.

Instead of recalculating durations on the fly during playback, the cleanest approach is to compile the input text into a flat, deterministic timetable before a single sound plays:

const MORSE_TABLE = {
  A: ".-", B: "-...", C: "-.-.", D: "-..", E: ".", F: "..-.",
  G: "--.", H: "....", I: "..", J: ".---", K: "-.-", L: ".-..",
  M: "--", N: "-.", O: "---", P: ".--.", Q: "--.-", R: ".-.",
  S: "...", T: "-", U: "..-", V: "...-", W: ".--", X: "-..-",
  Y: "-.--", Z: "--.."
};

export function buildTimetable(text, wpm = 20, spacingMultiplier = 1) {
  const ditMs = 1200 / wpm;
  const letterGapMs = ditMs * 3 * spacingMultiplier;
  const wordGapMs = ditMs * 7 * spacingMultiplier;

  const events = [];
  let cursorMs = 0;

  const words = text.trim().toUpperCase().split(/\s+/);

  words.forEach((word, wIndex) => {
    const letters = [...word];

    letters.forEach((char, lIndex) => {
      const pattern = MORSE_TABLE[char];
      if (!pattern) return;

      [...pattern].forEach((mark, mIndex) => {
        const durationMs = mark === "." ? ditMs : ditMs * 3;

        events.push({
          type: mark === "." ? "dit" : "dah",
          char,
          startMs: cursorMs,
          durationMs,
          endMs: cursorMs + durationMs
        });

        cursorMs += durationMs;

        // 1-unit gap between marks inside a letter (never scaled by Farnsworth)
        if (mIndex < pattern.length - 1) {
          cursorMs += ditMs;
        }
      });

      // 3-unit gap between letters
      if (lIndex < letters.length - 1) {
        cursorMs += letterGapMs;
      }
    });

    // 7-unit gap between words
    if (wIndex < words.length - 1) {
      cursorMs += wordGapMs;
    }
  });

  return { events, totalDurationMs: cursorMs, ditMs };
}

Because this timetable is just data, you can feed the exact same array to the audio engine, the SVG renderer, and the URL state serializer.

2. Eliminating "Key Clicks" on a 600 Hz Oscillator

If you start and stop an OscillatorNode abruptly, or snap a GainNode from 0 to 1 instantly, the speaker cone jumps mid-phase. That produces an audible popping sound known in radio as a key click.

To get a clean 600 Hz tone, keep a single oscillator running for the duration of the message and schedule the gain envelope on the AudioContext.currentTime hardware clock with a 4–5 ms rise and fall ramp:

export function playMorseAudio(audioCtx, events) {
  const osc = audioCtx.createOscillator();
  const gain = audioCtx.createGain();

  osc.type = "sine";
  osc.frequency.value = 600; // Standard 600 Hz CW pitch

  gain.gain.value = 0;
  osc.connect(gain);
  gain.connect(audioCtx.destination);

  const baseTime = audioCtx.currentTime + 0.05; // 50ms safety buffer
  const rampSec = 0.004; // 4ms anti-click envelope

  for (const ev of events) {
    const startSec = baseTime + ev.startMs / 1000;
    const endSec = baseTime + ev.endMs / 1000;

    gain.gain.setValueAtTime(0, startSec);
    gain.gain.linearRampToValueAtTime(1, startSec + rampSec);
    gain.gain.setValueAtTime(1, endSec - rampSec);
    gain.gain.linearRampToValueAtTime(0, endSec);
  }

  const lastEvent = events[events.length - 1];
  const stopSec = baseTime + (lastEvent ? lastEvent.endMs / 1000 : 0) + 0.1;

  osc.start(baseTime);
  osc.stop(stopSec);

  return { baseTime, stop: () => osc.stop() };
}

3. Syncing Visuals, Vibration, and the Rear Camera Flashlight

Once the Web Audio clock (audioCtx.currentTime) is running, the visual highlights shouldn't rely on independent timers. Instead, a requestAnimationFrame loop checks the elapsed time against baseTime and highlights whichever mark in events matches startMs <= elapsedMs < endMs.

Why 1:3 Visual Proportions Matter

On paper or a screen, typing .- with a standard font makes the dot and hyphen nearly the same width. When learners look at that and then listen to the audio, their eyes and ears disagree. Drawing a dit as a 1-unit bar and a dah as a 3-unit bar with a 1-unit gap between them makes the visual layout match the acoustic rhythm. (We use this same 1:3 proportional drawing engine in our printable Morse code worksheet generator so paper sheets match what students hear.)

Blinking the Hardware Flashlight on Android Chrome

One of the more fun browser APIs to wire up to the timetable is the phone's rear camera flash. On Android phones running Chrome, you can request a video track with the "environment" facing camera and toggle the torch constraint as each mark starts and ends:

async function createTorchController() {
  const stream = await navigator.mediaDevices.getUserMedia({
    video: { facingMode: "environment" }
  });
  const track = stream.getVideoTracks()[0];
  const capabilities = track.getCapabilities();

  if (!capabilities.torch) {
    track.stop();
    throw new Error("Torch constraint not supported on this device.");
  }

  return {
    setLight: (on) => track.applyConstraints({ advanced: [{ torch: Boolean(on) }] }),
    release: () => track.stop()
  };
}

A quick heads-up if you implement this: iPhones still do not let a web page switch the rear flash via MediaStreamTrack, so make sure to feature-detect capabilities.torch and degrade gracefully to a screen flash or haptic vibration (navigator.vibrate).

Wrapping Up

Keeping everything—from the translator and live microphone decoder to the printable reference trees—on a single client-side engine without cookies or server round-trips keeps the UI fast and predictable. If you want to test the live timing ruler, play with Farnsworth spacing, or try the flashlight output on Android, you can check it out at morseuniverse.com.

73! (Traditional radio operator sign-off for "best regards")