Projects

January 2026

Video Grabber - Chromium MV3 Browser Extension

TypeScript, React, yt-dlp, ffmpeg.wasm, OPFS, Chrome Extension APIs

I re-architected Video Grabber from a server/VPS model into a strict client-side Chromium MV3 extension using a background worker, offscreen WASM based yt-dlp and ffmpeg runtime, OPFS checkpoints, and resumable jobs.

Visit source
Video Grabber - Chromium MV3 Browser Extension cover image

Video Grabber

This project started as a very practical annoyance and then became a lesson in how weird browser extension architecture can get once you stop cheating with a server.

The original idea was simple: grab youtube videos from the browser, process them, and let the user keep the output. The first version leaned toward a server/VPS style runtime, which made the architecture easier in the short term but worse in the ways that matter.

It meant infrastructure. It meant trust boundaries. It meant depending on a backend for something that should ideally be local, which had to keep rotating IPs to bypass bot detection and a host of other issues.

So I hard-cut the old direction and rebuilt it as a strict client-side Chromium Manifest V3 extension.

The Runtime

Manifest V3 is not exactly a friendly place to build long-running media workflows. Service workers can sleep, browser APIs have sharp edges, and anything involving heavy processing needs to be carefully moved out of the wrong execution context.

The new architecture uses:

  • a background service worker as the control plane
  • an offscreen document for heavier WASM operations
  • ffmpeg.wasm for client-side media processing
  • an offscreen yt-dlp WASM-based runtime for the download/extraction side
  • OPFS checkpoints and chrome.storage metadata for resumable jobs

That means the browser itself owns the work. No VPS, no backend compatibility layer, nothing extra at all. Fully client side.

The Reliability Work

The part I like most about this project is not the happy path. It's the failure handling.

Browser-extension media work fails in annoying ways: network changes, tab state changes, runtime resets, permissions, storage limits, muxing errors, extraction breakage, policy concerns, and user behavior that doesn't follow the nice diagram in your head.

So I wrote the surrounding docs and internal structure for a deterministic error taxonomy, a recovery matrix, mux guardrails, a breakage triage runbook, a support contract, and an open-source distribution strategy (since I obviously couldn't publish this extension onto the Chrome Web Store as it breaks most of YouTube's T&Cs pretty intensively).

That sounds excessive until you realize that without it every failure just becomes "it broke" and every fix becomes vibes.

How this mattered to me:

This is one of those projects where the constraints are the whole point.

MV3 forces you to think about lifetimes. WASM forces you to think about cost and memory. OPFS forces you to think about recovery. Distribution policy forces you to think about what the project is allowed to be, not just what it can technically do.

It is a small extension on the surface, but underneath it is a compact systems problem: unreliable runtime, heavy media work, resumable state, and no server safety net.

Overall, the experience of building this was a little awkward, a little constrained, and very satisfying once the pieces finally lined up.

A couple of my friends and family use it at-least once every week, because running yt-dlp from the command line isn't everyone's cup of tea & that's what drove me to build this in the first place.

Projects

January 2026

Video Grabber - Chromium MV3 Browser Extension

TypeScript, React, yt-dlp, ffmpeg.wasm, OPFS, Chrome Extension APIs

I re-architected Video Grabber from a server/VPS model into a strict client-side Chromium MV3 extension using a background worker, offscreen WASM based yt-dlp and ffmpeg runtime, OPFS checkpoints, and resumable jobs.

Visit source
Video Grabber - Chromium MV3 Browser Extension cover image

Video Grabber

This project started as a very practical annoyance and then became a lesson in how weird browser extension architecture can get once you stop cheating with a server.

The original idea was simple: grab youtube videos from the browser, process them, and let the user keep the output. The first version leaned toward a server/VPS style runtime, which made the architecture easier in the short term but worse in the ways that matter.

It meant infrastructure. It meant trust boundaries. It meant depending on a backend for something that should ideally be local, which had to keep rotating IPs to bypass bot detection and a host of other issues.

So I hard-cut the old direction and rebuilt it as a strict client-side Chromium Manifest V3 extension.

The Runtime

Manifest V3 is not exactly a friendly place to build long-running media workflows. Service workers can sleep, browser APIs have sharp edges, and anything involving heavy processing needs to be carefully moved out of the wrong execution context.

The new architecture uses:

  • a background service worker as the control plane
  • an offscreen document for heavier WASM operations
  • ffmpeg.wasm for client-side media processing
  • an offscreen yt-dlp WASM-based runtime for the download/extraction side
  • OPFS checkpoints and chrome.storage metadata for resumable jobs

That means the browser itself owns the work. No VPS, no backend compatibility layer, nothing extra at all. Fully client side.

The Reliability Work

The part I like most about this project is not the happy path. It's the failure handling.

Browser-extension media work fails in annoying ways: network changes, tab state changes, runtime resets, permissions, storage limits, muxing errors, extraction breakage, policy concerns, and user behavior that doesn't follow the nice diagram in your head.

So I wrote the surrounding docs and internal structure for a deterministic error taxonomy, a recovery matrix, mux guardrails, a breakage triage runbook, a support contract, and an open-source distribution strategy (since I obviously couldn't publish this extension onto the Chrome Web Store as it breaks most of YouTube's T&Cs pretty intensively).

That sounds excessive until you realize that without it every failure just becomes "it broke" and every fix becomes vibes.

How this mattered to me:

This is one of those projects where the constraints are the whole point.

MV3 forces you to think about lifetimes. WASM forces you to think about cost and memory. OPFS forces you to think about recovery. Distribution policy forces you to think about what the project is allowed to be, not just what it can technically do.

It is a small extension on the surface, but underneath it is a compact systems problem: unreliable runtime, heavy media work, resumable state, and no server safety net.

Overall, the experience of building this was a little awkward, a little constrained, and very satisfying once the pieces finally lined up.

A couple of my friends and family use it at-least once every week, because running yt-dlp from the command line isn't everyone's cup of tea & that's what drove me to build this in the first place.