DEV Community: bagaje

Building a Compass in the Browser: How the DeviceOrientation API Actually Works

bagaje — Mon, 27 Jul 2026 12:37:17 +0000

Pull up any browser-based compass tool on your phone and it works instantly — no app install, no native code. That's not a trick; it's a real browser API doing real sensor fusion under the hood. Here's what's actually happening between "grant motion permission" and a needle pointing north.

The API: DeviceOrientationEvent

Browsers expose device orientation through the DeviceOrientationEvent, which fires continuously as the device moves and gives you three angles:

window.addEventListener('deviceorientation', (event) => {
  console.log(event.alpha); // compass heading, 0-360°
  console.log(event.beta);  // front-to-back tilt, -180 to 180°
  console.log(event.gamma); // left-to-right tilt, -90 to 90°
});

For a compass specifically, alpha is the value that matters — it represents rotation around the z-axis, i.e., which way the device is facing relative to north. beta and gamma describe tilt, which is useful for things like AR overlays but isn't the heading itself.

Where the numbers actually come from: sensor fusion

The browser doesn't read alpha directly off a single chip. It's computed from multiple hardware sensors combined:

Magnetometer — measures the ambient magnetic field in three axes, the same underlying sensor a standalone compass app uses
Accelerometer — measures gravity/tilt, used to figure out which way is "down" so the heading can be corrected for the phone not being held perfectly flat
Gyroscope — measures rotational velocity, used to smooth out jittery orientation changes between magnetometer readings

The OS-level sensor fusion algorithm (not something you write yourself) blends these three inputs together to produce a single, relatively stable heading value. This is why a compass built purely on deviceorientation tends to be smoother and more usable than one built by reading a raw magnetometer value alone — you're getting the benefit of tilt-compensation for free.

Absolute vs. relative orientation — the detail that trips people up

There are actually two related events, and mixing them up is one of the most common bugs in browser-compass implementations:

deviceorientation — heading may be relative to the device's initial orientation when the page loaded, not true compass north, depending on browser/platform
deviceorientationabsolute — explicitly ties the heading to Earth's magnetic north, which is what you actually want for a compass

On some platforms (notably iOS Safari), you instead get a non-standard property, event.webkitCompassHeading, which already gives you a proper 0–360° compass heading directly, and conveniently, direction is inverted relative to alpha (it increases clockwise, matching real-world compass bearings) — so implementations typically branch on feature detection:

function getHeading(event) {
  if (event.webkitCompassHeading !== undefined) {
    // iOS Safari: already a true compass heading
    return event.webkitCompassHeading;
  } else if (event.absolute && event.alpha !== null) {
    // Standard absolute orientation
    return 360 - event.alpha;
  }
  return null; // orientation not available/reliable
}

That 360 - event.alpha flip exists because alpha increases counter-clockwise in the spec, while compass bearings conventionally increase clockwise (N=0°, E=90°, S=180°, W=270°). It's a small detail, but it's exactly the kind of thing that makes a "compass" point the wrong way if you skip it.

The permission wall (and why it exists)

Since iOS 13, Safari requires an explicit, user-initiated permission request before orientation data is exposed at all — you can't request it on page load, only in direct response to a user gesture like a tap:

async function requestCompassPermission() {
  if (typeof DeviceOrientationEvent.requestPermission === 'function') {
    // iOS 13+ requires this explicit request, triggered by a user gesture
    const permission = await DeviceOrientationEvent.requestPermission();
    if (permission === 'granted') {
      window.addEventListener('deviceorientationabsolute', handleOrientation);
    }
  } else {
    // Other browsers: no explicit permission step needed
    window.addEventListener('deviceorientationabsolute', handleOrientation);
  }
}

button.addEventListener('click', requestCompassPermission);

This exists for a legitimate reason: orientation and motion data can be used for fingerprinting and, combined with other signals, for inferring things like typed input on nearby devices. The permission prompt is Apple's mitigation, and any browser-based compass has to design its UX around a real "tap to enable" step rather than assuming instant access.

HTTPS is non-negotiable

Motion and orientation sensors are gated behind a secure context requirement — they simply won't fire at all on a plain http:// page (localhost is exempted for development). This is standard practice for any sensor-adjacent Web API (camera, microphone, geolocation follow the same rule), so if you're testing this locally and getting null values, check your protocol before you start debugging the sensor logic itself.

Why accuracy still varies

Even with all of this correctly wired up, browser-based compass readings can wobble near metal objects, other electronics, or magnetic phone mounts — because the underlying magnetometer reading is still susceptible to local magnetic interference, exactly like a physical compass needle would be. Most implementations handle this with a simple moving average over the last several readings to smooth out jitter, rather than trying to correct interference at the software level, which is a much harder problem.

Seeing it working

If you want to see a working implementation rather than just the snippets above, online-compass.com is a browser-based compass built entirely on this API — no native app, just deviceorientationabsolute/webkitCompassHeading feature-detection and the permission flow described above, running directly in the page.
online compass

The takeaway

A browser compass isn't reading a single "direction" sensor — it's consuming an OS-level sensor-fusion output (magnetometer + accelerometer + gyroscope), gated behind a secure-context and user-permission requirement, with just enough platform inconsistency (alpha vs. webkitCompassHeading, relative vs. absolute) to make correct implementation more fiddly than it first appears. Once you know where the numbers come from and which event to actually listen for, it's a surprisingly small amount of code for something that feels like magic on first use.

How Silence Detection Works: RMS, Thresholds, and Audio Signal Processing Basics

bagaje — Mon, 27 Jul 2026 12:26:39 +0000

Every podcast editor, video creator, and voice-app developer eventually runs into the same problem: trimming dead air out of an audio file. It sounds like a UI feature, but underneath it's a genuinely interesting signal-processing problem — how do you get a computer to reliably tell the difference between "silence" and "someone talking quietly"?

Let's break down how it actually works.

Audio as numbers, not sound

Before any detection happens, it helps to remember what a digital audio file actually is: a sequence of numbers. Each number is a sample — the amplitude of the sound wave measured at a single instant in time. A typical audio file samples the waveform 44,100 times per second (44.1kHz), and each sample is just a value representing how far the waveform has displaced from zero at that instant.

Silence, in this representation, isn't a special flag — it's simply a long stretch of samples sitting very close to zero.

The core metric: RMS (Root Mean Square)

You can't just check if a single sample equals zero — real audio (even "silent" recordings) contains tiny amounts of background noise, microphone hiss, and quantization artifacts that make individual samples jitter slightly around zero. Checking one sample at a time is noisy and unreliable.

Instead, silence detection works over small windows of audio (say, 20–50 milliseconds at a time) and calculates the RMS (Root Mean Square) — a measure of the average energy in that window:

function calculateRMS(samples) {
  let sumOfSquares = 0;
  for (let i = 0; i < samples.length; i++) {
    sumOfSquares += samples[i] * samples[i];
  }
  return Math.sqrt(sumOfSquares / samples.length);
}

Squaring each sample before averaging does two useful things: it makes every value positive (so positive and negative parts of the waveform don't cancel out), and it weights louder moments more heavily than quiet ones — which tends to match how we perceive loudness better than a simple average would.

Setting the threshold

Once you have an RMS value per window, silence detection becomes a threshold comparison:

const SILENCE_THRESHOLD = 0.01; // tune per use case
const isSilent = calculateRMS(window) < SILENCE_THRESHOLD;

This sounds simple, but the threshold is where most of the real engineering work happens. Set it too high, and quiet speech gets chopped out as if it were silence. Set it too low, and background hiss or room noise never gets flagged as silence at all. Good implementations often:

Convert RMS to decibels (a logarithmic scale) since human perception of loudness is logarithmic, not linear — this makes thresholds behave more consistently across different recording levels
Use an adaptive threshold that adjusts based on the noise floor of the specific file, rather than one fixed number for every recording
Require silence to persist for a minimum duration (e.g., 300ms+) before trimming it, so brief pauses between words aren't mistaken for gaps to cut
From detection to trimming

Detecting silence and removing it are two different steps. Once you've classified each window as silent or not, the trimming logic typically:

Walks through the windows and groups consecutive "silent" windows into ranges
Discards ranges shorter than the minimum-duration threshold (to avoid destroying natural speech pauses)
Either deletes the remaining silent ranges outright, or compresses them down to a short fixed gap (many tools prefer this — full removal can make speech sound unnaturally rushed, while a small fixed gap preserves natural pacing)
Stitches the surviving audio segments back together

That last point matters more than it sounds: naive full-silence-removal often makes speech sound clipped and breathless, because natural human speech relies on pause length for rhythm and emphasis. Better tools shorten pauses rather than eliminating them entirely.

This is a simplified form of Voice Activity Detection (VAD)

What's described above is essentially a lightweight version of Voice Activity Detection, a well-studied problem in speech processing used in everything from mobile calling (to save bandwidth during silence) to transcription pipelines (to skip processing dead air) to hearing aids. Production-grade VAD systems often go further than a raw RMS threshold — using spectral features, zero-crossing rate, or trained models to distinguish speech from non-speech noise (like a fan or keyboard clicks) more reliably than energy alone can.

For most editing use cases, though, a well-tuned RMS/decibel threshold with a minimum-duration rule gets you very close to production quality without needing a trained model at all.

Doing this entirely in the browser

Modern browsers expose the Web Audio API, which lets you decode and analyze audio samples directly in JavaScript — no server round-trip required:

async function analyzeAudioFile(file) {
  const audioContext = new AudioContext();
  const arrayBuffer = await file.arrayBuffer();
  const audioBuffer = await audioContext.decodeAudioData(arrayBuffer);
  const channelData = audioBuffer.getChannelData(0); // Float32Array of samples
  return channelData;
}

Once you have channelData as a raw array of samples, everything above — windowing, RMS calculation, thresholding — runs client-side. That's the approach behind browser-based tools like audiosilenceremover.com: the audio file is decoded and processed directly in the browser, which means large files never need to be uploaded to a server just to trim a few gaps out.

The takeaway

Silence detection isn't magic — it's windowed energy measurement (RMS) compared against a tuned threshold, with a minimum-duration rule to protect natural speech pauses. The hard part isn't the math, which is simple; it's tuning the threshold and duration rules so the result sounds natural instead of robotic. Once you understand it as an energy-over-time problem, it stops being a black box and starts being something you could implement yourself in an afternoon.

How ZIP Compression Actually Works: LZ77, Huffman Coding, and DEFLATE Explained

bagaje — Mon, 27 Jul 2026 12:21:42 +0000

You've zipped a folder a thousand times. But what's actually happening inside that .zip file? It's not one trick — it's two classic algorithms stacked on top of each other, and understanding them makes you better at reasoning about performance, file sizes, and when compression will (and won't) help you.

Let's open the hood.

The two-stage pipeline: DEFLATE

Almost every ZIP file uses an algorithm called DEFLATE, which itself is a combination of two separate compression techniques run back to back:

LZ77 — removes repetition
Huffman coding — removes statistical redundancy

Each stage attacks a different kind of waste in your data. Together, they cover most of what makes text, code, and structured files compressible at all.

Stage 1: LZ77 — finding repeated patterns

Most real-world files are full of repetition. Source code repeats keywords and variable names. English text repeats common words. LZ77 exploits this by replacing repeated sequences with a back-reference instead of storing them again.

Concretely, LZ77 slides a window over your data and, whenever it spots a sequence that already appeared recently, it replaces it with a triplet:

(distance, length, next_literal)

Take this (deliberately repetitive) string:

the cat sat on the mat, the cat ran

The second occurrence of "the cat" doesn't need to be stored character by character — LZ77 can just say "go back 20 characters, copy 7 characters." A tiny pointer replaces a chunk of text.

A simplified version of the core idea in JavaScript:

function findLongestMatch(data, pos, windowSize = 32) {
  let bestLength = 0;
  let bestDistance = 0;
  const start = Math.max(0, pos - windowSize);

  for (let i = start; i < pos; i++) {
    let length = 0;
    while (
      pos + length < data.length &&
      data[i + length] === data[pos + length]
    ) {
      length++;
    }
    if (length > bestLength) {
      bestLength = length;
      bestDistance = pos - i;
    }
  }
  return { distance: bestDistance, length: bestLength };
}

This is the naive O(n·windowSize) version — real implementations (like zlib) use hash chains to find matches far faster, but the underlying logic is exactly this: look back, find the longest match, replace it with a pointer.

Stage 2: Huffman coding — squeezing the leftovers

After LZ77 removes repetition, you're left with a stream of literals and back-references. Some of those symbols show up far more often than others — and that's exactly what Huffman coding exploits.

Standard text encoding (like ASCII) gives every character a fixed number of bits, regardless of how common it is. Huffman coding throws that out and assigns shorter bit-codes to frequent symbols and longer codes to rare ones — built from a binary tree where common characters sit near the root.

Example: if e and t appear constantly in your file but q and z barely show up, Huffman coding might represent e in 3 bits and q in 9 bits, instead of giving both a flat 8 bits. Across a whole file, that adds up fast.

This is why DEFLATE runs Huffman after LZ77 — LZ77's output (a mix of literals and distance/length pairs) still has an uneven symbol frequency distribution that Huffman can exploit further.

Why some files barely compress at all

This two-stage model explains a question devs ask constantly: "Why doesn't zipping my already-compressed files (JPEGs, MP4s, another ZIP) shrink them much?"

Both LZ77 and Huffman coding rely on redundancy — repeated patterns and uneven symbol frequency. Formats like JPEG and MP4 are already compressed, which means their output is close to random-looking, high-entropy data with very little repetition left to exploit. Compressing already-compressed data is close to compressing noise — there's nothing left for LZ77 to find or Huffman to reweight.

This is also why plain text, source code, JSON, CSV, and uncompressed formats (BMP, WAV) compress dramatically better than images or video — they're full of exactly the redundancy DEFLATE is designed to eliminate.

Client-side (browser) ZIP compression

Traditionally, compression happened entirely on a server: you upload a file, a backend process runs zlib or similar, and you download the result. Modern browsers can now do this entirely client-side, using either:

The native Compression Streams API (CompressionStream('deflate')), supported in most modern browsers, or
JS libraries like pako (a port of zlib to WebAssembly/JS) or JSZip for building actual .zip archives with headers, directory structure, and metadata

A minimal example using the native API:

async function compressFile(file) {
  const stream = file.stream().pipeThrough(new CompressionStream('deflate'));
  const compressedBlob = await new Response(stream).blob();
  return compressedBlob;
}

The practical upside of doing this in-browser rather than server-side: the file never leaves the user's device. For anyone compressing sensitive documents, that's a meaningful privacy difference, not just a convenience one — it's the same principle behind tools like compress zip file, which handles ZIP compression directly in the browser instead of routing files through a server.

The takeaway

ZIP compression isn't one algorithm — it's LZ77 eliminating repeated sequences, followed by Huffman coding eliminating statistical redundancy in what's left. Once you see it as that two-stage pipeline, a lot of practical compression behavior — why text compresses well, why media files don't, why "zipping a zip" does nothing — stops being a mystery and starts being predictable.