DEV Community: monkeymore studio

60 FPS with 600 Snakes: How I Got the Browser Client to Survive a Room Full of Snakes

monkeymore studio — Mon, 11 May 2026 08:11:46 +0000

The server took me one week. The client took another. Phaser 3 + React 19 + Vite. I know there are magic numbers, TODO comments, and obviously cleaner ways to write half of it — but it runs at a steady 60 FPS on a regular laptop, and that's good enough for a side project.

This post is about how I kept the browser from dying.

1. Why Mix React and Phaser?

I first tried building the UI entirely inside Phaser. Bad idea — Phaser's UI system is painful for anything beyond a score counter. I ended up with React 19 + Tailwind CSS for menus, HUD, and leaderboard, and Phaser 3 for the game canvas. They communicate through callbacks: React sends commands to Phaser, Phaser pushes score and leaderboard data back to React.

The upside is React's reconciliation never touches the game render loop because the Phaser canvas and React DOM live in separate worlds.

┌─────────────────────────────────────┐
│  React DOM (Tailwind CSS)           │
│  - Main menu, HUD, leaderboard      │
│  - Skin selector, i18n              │
└──────────────┬──────────────────────┘
               │ props / callbacks
┌──────────────▼──────────────────────┐
│  Phaser 3 Game                      │
│  - NetworkedGameScene               │
│  - WebSocket input / state sync     │
│  - 60 FPS fixed-timestep loop       │
└─────────────────────────────────────┘

Client Architecture Flow

My targets were modest but tricky:

60 FPS while rendering 100 visible snakes and ~200 food items.
Input latency < 50 ms — the mouse must feel instant.
Remote snakes must move smoothly, never snap to position.

2. Viewport Culling: The Foundation of Scale

The single most important optimization is don't render what the player cannot see. On a 16,000×16,000 map with 600 snakes, creating every Phaser game object every frame would obliterate the frame rate.

2.1 ViewportManager

class ViewportManager {
    viewRadius: number = 1000;   // strict visible radius
    bufferRadius: number = 100;  // hysteresis buffer

    isInViewport(x, y, centerX, centerY): boolean {
        const dist = sqrt((x - centerX)² + (y - centerY)²);
        return dist < (viewRadius + bufferRadius);
    }

    updateViewRadius() {
        const w = scene.cameras.main.width;
        const h = scene.cameras.main.height;
        // Cap at 1200 px to limit max render load regardless of monitor size
        this.viewRadius = min(sqrt(w² + h²) / 2 + 100, 1200);
    }
}

The buffer radius prevents objects at the screen edge from flickering in and out as the camera moves. An object must move 100 px beyond the visible edge before its render objects are destroyed.

2.2 Lazy Render-Object Lifecycle

Each snake has two layers:

Layer	Cost	Lifetime
`LocalSnake` (data)	Cheap (numbers + arrays)	Permanent while snake exists in server state
Phaser objects (head, eyes, body circles, text)	Expensive (GPU textures, draw calls)	Only while snake is in viewport

// On server state update
for each snake in state:
    const inViewport = viewportManager.isInViewport(snake.x, snake.y, cameraCenter);

    if (inViewport && !snake.isRendered):
        snake.createRenderObjects();   // Allocate Phaser objects
    else if (!inViewport && snake.isRendered):
        // 3-second grace period before destroying (anti-flicker)
        if (now - snake.lastVisibleTime > 3000):
            snake.destroyRenderObjects(); // Free GPU resources

Why destroy instead of hide? I originally used setVisible(false). Frame rate barely improved. Then I read the Phaser docs and realized GameObjects still participate in internal updates — tweens, transforms, culling checks — even when invisible. Only destroy() removes them from the scene graph entirely. That debugging session ate my entire afternoon.

Lazy Render Lifecycle Flow

2.3 Food Culling

Food uses the same pattern:

for each food in serverState:
    const inViewport = viewportManager.isInViewport(food.x, food.y, centerX, centerY);

    if (inViewport && !foods.has(foodId)):
        createFoodSprite(food);      // Spawn new circle
    else if (!inViewport && foods.has(foodId)):
        destroyFoodSprite(foodId);   // Immediate cleanup
    else if (inViewport && foods.has(foodId)):
        updateFoodPosition(food);    // Magnetic attraction movement

With 1,600 total food items, typically only 80–150 are visible at once. That 90% reduction is the single biggest reason I can hold 60 FPS.

3. Client-Side Prediction & Server Reconciliation

My first attempt was pure server-authoritative: send input, wait for the server, then move. Even 50 ms of latency felt like dragging through mud. I switched to client prediction + server reconciliation.

3.1 Prediction (Local Player)

Every frame I simulate the local snake forward using the exact same physics constants as the server:

predict(inputAngle: number, isBoosting: boolean, deltaTime: number) {
    const speed = isBoosting ? BOOST_SPEED : BASE_SPEED;
    const dt = deltaTime / 1000;

    const vx = cos(inputAngle) * speed * dt;
    const vy = sin(inputAngle) * speed * dt;

    this.x += vx;
    this.y += vy;
    this.angle = inputAngle;

    this.updateTrail(this.x, this.y);   // Same trail algorithm as server
}

This runs at 60 Hz inside the fixed-tick loop. The player feels zero input latency.

3.2 Interpolation (Remote Players)

Other players cannot be predicted — I don't know their inputs. Instead I interpolate toward the latest server position:

interpolate(deltaTime: number) {
    // Lerp toward server state at 20% per frame
    this.x = lerp(this.x, this.serverX, 0.2);
    this.y = lerp(this.y, this.serverY, 0.2);

    // Angle wrap-around for shortest path
    let angleDiff = this.serverAngle - this.angle;
    while (angleDiff > PI)  angleDiff -= 2*PI;
    while (angleDiff < -PI) angleDiff += 2*PI;
    this.angle += angleDiff * 0.2;

    this.updateTrail(this.x, this.y);
}

0.2 is a value I tuned by hand.

Above 0.5: jerky, snaps to server state.
Below 0.1: sluggish, feels underwater.
0.2 felt right after an evening of tweaking.

3.3 Reconciliation

Prediction inevitably drifts from the server. I reconcile in two layers:

reconcile() {
    const diffX = this.serverX - this.x;
    const diffY = this.serverY - this.y;

    // Small drift: invisible 5% nudge per frame
    if (abs(diffX) > 1 || abs(diffY) > 1) {
        this.x += diffX * 0.05;
        this.y += diffY * 0.05;
    }

    // Large drift (> 100 px): teleport and reset trail
    if (abs(diffX) > 100 || abs(diffY) > 100) {
        this.x = this.serverX;
        this.y = this.serverY;
        this.initTrail();   // Rebuild from new position
    }
}

The 5% nudge absorbs normal tick drift. Players never notice it. The 100 px hard-sync handles respawns, lag spikes, or anything else where smooth correction would look weirder than a snap.

Prediction & Reconciliation Flow

4. Trail-Based Snake Rendering

I use the same trail-following algorithm on the client that I built for the server. My first attempt simulated every body segment with independent physics. Frame rate died instantly.

4.1 Algorithm

TRAIL_STEP = 2;           // pixels between trail points
SEGMENT_DISTANCE = 10;    // pixels between body segments

updateTrail(headX: number, headY: number) {
    const dist = distance(lastHeadPosition, {x: headX, y: headY});

    if (dist >= TRAIL_STEP) {
        const steps = floor(dist / TRAIL_STEP);
        for (let i = 1; i <= steps; i++) {
            const t = i / steps;
            trail.unshift({
                x: lerp(lastHeadPosition.x, headX, t),
                y: lerp(lastHeadPosition.y, headY, t)
            });
        }
        lastHeadPosition = {x: headX, y: headY};

        // Prevent unbounded growth
        const maxPoints = (bodySegments + 2) * (SEGMENT_DISTANCE / TRAIL_STEP);
        if (trail.length > maxPoints) trail.splice(maxPoints);
    }
}

getSegmentPositions(): Vector2[] {
    const pointsPerSegment = SEGMENT_DISTANCE / TRAIL_STEP;  // = 5
    const positions = [];
    for (let i = 0; i < bodySegments; i++) {
        const idx = floor((i + 1) * pointsPerSegment);
        if (trail[idx]) positions.push({...trail[idx]});
    }
    return positions;
}

4.2 Why This Is Fast

One head simulation per snake, not N body segments.
Trail is a flat array — no linked lists, no complex structures.
Segment positions are pure lookups into the trail array, zero physics.
Memory is bounded: max 400 segments × 5 points/segment ≈ 2,000 vectors per snake.

Trail Update Flow

5. Render Optimizations in Detail

5.1 Body-Part Culling

Even when a snake is in viewport, not all its body segments need to be visible:

for (let i = 0; i < bodyParts.length; i++) {
    const partInViewport = viewportManager.isInViewportStrict(
        positions[i].x, positions[i].y, centerX, centerY
    );
    bodyParts[i].setVisible(partInViewport || this.isLocalPlayer);
}

The local player's entire body is always rendered (so the tail is visible when wrapping around), but remote snakes hide off-screen segments.

5.2 Dynamic Body-Part Allocation

I do not pre-allocate all 400 possible segments. I grow and shrink dynamically:

// Grow
while (bodyParts.length < positions.length) {
    const part = scene.add.circle(0, 0, radius * 0.9, 0xffffff);
    bodyParts.push(part);
}

// Shrink
while (bodyParts.length > positions.length) {
    bodyParts.pop()?.destroy();
}

This prevents allocating hundreds of invisible circles for every newly spawned snake.

5.3 Visual Tapering

To make long snakes look organic, the radius tapers toward the tail:

const taperFactor = 1 - (i / bodyParts.length) * 0.3;
bodyParts[i].setRadius(radius * 0.9 * taperFactor);

Computationally trivial, but the visual improvement is huge without extra sprites or textures.

5.4 Skin Caching

Custom skins read from localStorage. I originally read it every frame and noticed occasional frame drops. Now I read once on skin change and cache:

loadCustomSkin() {
    if (skinId === 'custom') {
        const cfg = loadCustomSkinConfig();   // Reads localStorage once
        this.customHeadColor = hexToNumber(cfg.headColor);
        this.customBodyColors = cfg.bodyColors.map(hexToNumber);
    }
}

localStorage is only accessed when the skin changes, never during the render loop.

5.5 Lightweight Food Effects

I skipped post-processing shaders — Phaser's postFX is expensive on low-end machines. I use simple tweens:

// Normal food: gentle pulse
tweens.add({
    targets: food,
    alpha: { from: 0.6, to: 1 },
    scale: { from: 0.9, to: 1.1 },
    duration: 800 + random() * 400,
    yoyo: true,
    repeat: -1,
    ease: 'Sine.easeInOut'
});

No postFX, no particle emitters — just alpha and scale that the GPU handles for free.

6. Network Efficiency

6.1 Input Throttling

My first attempt sent a WebSocket message on every pointermove. With fast mouse movement that hit hundreds of messages per second and choked the connection. I switched to a fixed 60 Hz sample rate:

this.time.addEvent({
    delay: 1000 / 60,      // 16.67 ms
    callback: sendInput,
    loop: true
});

sendInput() {
    ws.send(JSON.stringify({
        type: 'input',
        angle: this.inputAngle,
        boosting: this.isBoosting
    }));
}

Upload bandwidth is now hard-capped at ~60 small JSON messages/second, no matter how fast the mouse moves.

6.2 Client-Authoritative Food Eating

To hide network latency, the client predicts food collisions locally:

private checkLocalPlayerFoodCollision() {
    const eatRadius = snake.radius + 20;  // Looser than server

    foods.forEach((foodObj, foodId) => {
        const dist = distance(snake, foodObj);
        if (dist < eatRadius) {
            // 1. Apply locally immediately
            snake.score += foodValue;
            snake.bodySegments = calculateBodySegments(snake.score);
            snake.radius = calculateSnakeRadius(snake.bodySegments);

            // 2. Notify server (fire-and-forget)
            ws.send(JSON.stringify({ type: 'eat_food', foodId }));

            // 3. Remove from scene immediately
            foodObj.destroy();
            foods.delete(foodId);
        }
    });
}

The player sees the score increase instantly. If the server rejects the eat (rare because of lenient validation), the next state sync silently corrects it. The 20 px extra radius absorbs client-server drift.

Client Network Flow

7. Minimap & Leaderboard

7.1 Minimap

The minimap is drawn with raw Graphics primitives, not sprites:

drawMinimap() {
    minimapGraphics.clear();
    // Background circle
    minimapGraphics.fillStyle(0x000000, 0.5);
    minimapGraphics.fillCircle(cx, cy, MINIMAP_SIZE / 2);

    const scale = MINIMAP_SIZE / WORLD_SIZE;

    // One draw call per snake: fillCircle
    snakes.forEach(snake => {
        if (snake.isAlive) {
            minimapGraphics.fillStyle(color, opacity);
            minimapGraphics.fillCircle(
                x + snake.x * scale,
                y + snake.y * scale,
                radius
            );
        }
    });
}

Using Graphics avoids the scene-graph overhead of hundreds of individual game objects.

7.2 Leaderboard Throttling

Sorting all snakes by score is expensive. I run it only once per second, not every frame:

this.time.addEvent({
    delay: 1000,
    callback: updateLeaderboard,
    loop: true
});

8. Fixed-Timestep Game Loop

The client uses the same fixed-timestep strategy as the server for deterministic physics:

update(time: number, delta: number) {
    this.elapsedTime += delta;
    while (this.elapsedTime >= this.fixedTimeStep) {
        this.elapsedTime -= this.fixedTimeStep;
        this.fixedTick(time, this.fixedTimeStep);
    }

    // Reconciliation and rendering happen every display frame
    if (this.currentPlayer) this.currentPlayer.reconcile();
    this.renderVisibleEntities();
}

Logic (prediction, interpolation) runs at 60 Hz.
Rendering runs at the display refresh rate (60 Hz, 120 Hz, 144 Hz).
If the display drops a frame, logic catches up by running multiple fixed ticks in one render frame.

Main Update Loop Flow

9. Performance Budget

System	Max Count	Optimization	Typical Active
Snakes (data)	600	Always stored	600
Snakes (rendered)	600	Viewport culling	20–60
Body segments	400 per snake	Dynamic allocation + per-segment culling	2,000–5,000
Food (total)	1,600	Viewport culling	80–150
Food effects	1,600	Simple tweens only	80–150
Minimap dots	600	Graphics primitives	600 (one batch)
Input messages	—	60 Hz throttle	60/s
State broadcasts	—	Server sends 20 Hz	20/s

10. One Week Later: Honest Thoughts

It works. Looking back, plenty I would rewrite:

Viewport culling saved the project. Without it, 600 snakes × 400 segments = 240,000 Phaser circles. Chrome would die.
Destroy, don't hide. I learned this the hard way. Phaser's scene graph is not free. destroy() gave me back 20 FPS compared to visible = false.
Predict locally, reconcile gently. The 5% per-frame nudge is invisible to players but keeps server and client aligned. Without it, drift becomes visible after a few seconds.
Mirror server physics exactly. BASE_SPEED, BOOST_SPEED, TRAIL_STEP — these numbers must match on both sides or reconciliation triggers hard-syncs constantly.
Throttle the expensive stuff. Leaderboard sorting, invisible object cleanup, input sending — none of this needs to run every frame.

All in all, going from zero to a playable multiplayer game in two weeks (one for server, one for client) feels pretty good. The code is rough, but it ships. If you want to borrow ideas or fork it, go ahead.

Want to try it yourself? Head over to Hi! Snake and see how long you can survive against 500 bots.

600 Snakes on the Edge: How I Built a Slither.io Server with Trail Algorithms, Spatial Hashing & Bot AI

monkeymore studio — Mon, 11 May 2026 08:06:33 +0000

I spent one week building a multiplayer Slither.io clone. The server runs on PartyKit + TypeScript, the client on Phaser 3 + React. Honestly the code is far from perfect — there are hard-coded magic numbers, TODO comments, and parts I would definitely refactor if I had more time — but it works. One room supports 600 snakes (100 real players + 500 bots) and the latency feels fine.

This post is about the core algorithms and the bugs I stepped on.

1. Why PartyKit?

I initially wanted to write the server with plain Node.js + WebSocket, but deployment and horizontal scaling looked like a nightmare. Then I found PartyKit. It compiles to Cloudflare Workers / Durable Objects, so each room is a single Durable Object with all state in memory. No Redis, no database, no ops headache. For a one-week side project, that was perfect.

My goal: one room, 100 human players + 500 AI bots, on a 16,000 × 16,000 world. Not huge, but not tiny either — one sloppy algorithm and the event loop stutters, sending every snake teleporting forward.

I gave myself three hard constraints:

Authoritative server: All movement, collision, and scoring computed server-side. The client only renders.
Low bandwidth: Cannot broadcast full state every tick or 600 entities would saturate the pipe.
Client-prediction friendly: The server must tolerate small client-side prediction errors, or players will scream "I clearly ate that!"

2. Fixed-Timestep Game Loop: Why I Cap maxSteps at 3

My first game loop was naive: setInterval(() => tick(), 16). During testing I noticed that whenever the event loop hiccuped — garbage collection, a burst of messages — deltaTime would balloon to 100 ms and tick() would fire six times in a row. The snakes would lurch forward in a sickening speed-up. Players hated it.

I switched to a semi-fixed timestep:

fixedTimeStep = 1000 / 60 ≈ 16.667 ms
maxStepsPerFrame = 3

function runGameLoop():
    now = currentTime()
    deltaTime = now - lastTickTime
    lastTickTime = now
    elapsedTime += deltaTime

    steps = 0
    while elapsedTime >= fixedTimeStep and steps < maxStepsPerFrame:
        elapsedTime -= fixedTimeStep
        fixedTick(fixedTimeStep)
        steps += 1

    schedule next runGameLoop after fixedTimeStep

Why cap maxSteps?

Without the cap, an event-loop stall causes the server to simulate a dozen frames at once. The snakes teleport. I set the cap to 3 steps (~50 ms of catch-up). I would rather drop temporal accuracy than let players see that teleport.

Here is the full loop flow:

Per-Tick Pipeline (fixedTick)

Phase	Description
1. Bot AI update	Every 3rd tick (20 Hz) to save CPU
2. Snake movement	Process input queues, advance trail, update segments
3. Collision detection	Spatial-grid broadphase + narrowphase
4. Food physics	Apply magnetic attraction velocities
5. Bot lifecycle	Spawn, respawn check every 5 s
6. State broadcast	Every 3rd tick (~50 ms)

3. Snake Movement: The Trail-Following Algorithm I'm Most Proud Of

My first idea was to simulate every body segment as an independent rigid body — head pulls segment 1, segment 1 pulls segment 2, and so on. It failed for two reasons: 400 segments per snake crushed the CPU, and the body would glitch out — snapping, bunching, occasionally detaching.

Then I flipped the problem: simulate only the head, derive the entire body from a history trail.

Data Structures

class ServerSnake {
  x, y: number;           // Head position
  angle: number;          // Heading in radians
  trail: Vector2[];       // Dense history of head positions
  segmentsX: number[];    // Derived body segment X positions
  segmentsY: number[];    // Derived body segment Y positions
  bodySegments: number;   // Count of visible segments
}

trail is a dense array of head positions sampled every TRAIL_STEP = 2 pixels.
segmentsX/Y are not independently simulated — they are read-only lookups into the trail.

Head Movement

Each tick the head moves forward based on its angle:

speed = isBoosting ? BOOST_SPEED(380) : BASE_SPEED(180)  // px/s
vx = cos(angle) * speed * dt
vy = sin(angle) * speed * dt
newHeadX = x + vx
newHeadY = y + vy

Trail Recording with Linear Interpolation

When the head moves farther than TRAIL_STEP, I interpolate intermediate points so the trail stays uniformly spaced:

distMoved = distance(lastHeadPosition, newHeadPosition)
if distMoved >= TRAIL_STEP:
    steps = floor(distMoved / TRAIL_STEP)
    for i = 1 to steps:
        t = i / steps
        interX = lastHeadPosition.x + (newHeadX - lastHeadPosition.x) * t
        interY = lastHeadPosition.y + (newHeadY - lastHeadPosition.y) * t
        trail.unshift({x: interX, y: interY})   // newest at front

    lastHeadPosition = {x: newHeadX, y: newHeadY}

    // Trim to prevent memory leaks
    maxPoints = (bodySegments + 2) * (SEGMENT_DISTANCE / TRAIL_STEP)
    if trail.length > maxPoints:
        trail.splice(maxPoints)

Interpolation is critical. Without it, high-speed movement lets the head outrun the body, creating visible gaps.

Segment Derivation

Body segments sample the trail at fixed intervals:

pointsPerSegment = SEGMENT_DISTANCE / TRAIL_STEP   // 10 / 2 = 5
for i = 0 to bodySegments - 1:
    trailIndex = floor((i + 1) * pointsPerSegment)
    segmentsX[i] = trail[trailIndex].x
    segmentsY[i] = trail[trailIndex].y

Segment 0 is the neck, the last segment is the tail. Because the trail is dense and pre-interpolated, the body follows the head with zero additional physics.

Growth & Shrinking

When a snake eats food or boosts, bodySegments changes. I reconcile the trail length like this:

newSegments = calculateBodySegments(score)
newRadius   = calculateSnakeRadius(newSegments)

// Extend trail if needed
pointsNeeded = (newSegments + 2) * (SEGMENT_DISTANCE / TRAIL_STEP)
while trail.length < pointsNeeded:
    trail.push(copy of last trail point)

// Extend segment arrays
while segmentsX.length < newSegments:
    segmentsX.push(lastTrailPoint.x)
    segmentsY.push(lastTrailPoint.y)

New segments spawn at the tail position, so the snake visibly grows from the back.

The complete movement flow:

4. Spatial-Grid Collision: How I Dropped O(n²) to O(n)

Brute-force snake-to-snake collision for 600 snakes is 180,000 checks per tick — instant death.

I implemented a uniform spatial grid for broadphase culling.

Grid Construction

gridSize = 200 px
grid: Map<string, Snake[]>   // key = "gridX,gridY"

for each snake:
    if not alive: continue
    gridX = floor(snake.x / gridSize)
    gridY = floor(snake.y / gridSize)
    key = "${gridX},${gridY}"
    grid[key].push(snake)

Neighbor Query Only

For each snake I only check the same cell plus the 8 adjacent cells:

for each cell in grid:
    for each snake in cell:
        checkFoodCollisions(snake)

        gx, gy = parse cell key
        for dx = -1 to 1:
            for dy = -1 to 1:
                neighborKey = "${gx+dx},${gy+dy}"
                for other in grid[neighborKey]:
                    if other != snake and other.isAlive:
                        checkSnakeCollision(snake, other)

        // World boundary
        if snake.x < 0 or snake.x > mapWidth or snake.y < 0 or snake.y > mapHeight:
            handleSnakeDeath(snake)

On a 16,000×16,000 map with 200 px cells there are 6,400 cells. With 600 snakes, most cells hold 0 or 1 snake. The inner loop runs in effectively O(n).

Narrowphase: Snake vs. Snake

The collision shape is the head circle tested against all opponent segment circles:

segments = [{x: other.x, y: other.y}]   // opponent head
for i = 0 to other.bodySegments - 1:
    segments.push({x: other.segmentsX[i], y: other.segmentsY[i]})

collisionDist = snake.radius + other.radius - 5   // 5px forgiveness
for segment in segments:
    dist = distance(snake.head, segment)
    if dist < collisionDist:
        handleSnakeDeath(snake)
        return

That -5 is my forgiveness margin. Without it, network jitter causes false-positive deaths and players rage-quit.

Full collision flow:

Food Collision & Magnetic Attraction

I skipped spatial partitioning for food. There are only 1,600 items, so O(1,600) per snake per tick is ~1M distance checks — well within what a PartyKit Durable Object can handle.

The magnetic attraction uses linear attenuation:

attractSpeed = 150 * (1 - dist / (snake.radius * 6))

Strongest at contact, zero at 6×radius. It feels great and costs almost nothing.

5. Bot AI: Keeping 500 Bots from Melting the CPU

I needed bots to fill rooms and give human players targets. The AI had to be stupidly cheap because 500 bots updating at 20 Hz adds up fast.

State Machine

Two states:

WANDERING — pick a random target, steer toward it
AVOIDING — threat within 150 px, steer away

Target Selection

margin = 200 px
targetX = margin + random() * (WORLD_SIZE - margin * 2)
targetY = margin + random() * (WORLD_SIZE - margin * 2)
changeTargetTimer = 3000 + random() * 4000 ms

Threat Detection

for each otherSnake in world:
    if otherSnake == this or not alive: continue
    dist = distance(this.head, otherSnake.head)
    if dist < 150:
        threatAngle = atan2(this.y - otherSnake.y, this.x - otherSnake.x)
        state = AVOIDING
        avoidTimer = 1000 ms

Only head-to-head distance. Bots do not anticipate body collisions — too expensive.

Smooth Steering

angleDiff = targetAngle - currentAngle
while angleDiff > PI:  angleDiff -= 2*PI
while angleDiff < -PI: angleDiff += 2*PI

maxTurn = 3 * dt
angleDiff = clamp(angleDiff, -maxTurn, maxTurn)
currentAngle += angleDiff

The ±2π wrap and turn-rate clamp were deliberate. Without them bots snap-turn instantly and look fake.

Boosting

shouldBoost = random() < 0.05

Completely random. I added BOOST_MIN_SCORE = 20 so bots don't boost themselves to death immediately after spawn.

Bot decision flow:

6. Growth & Scoring Formulas

Constant	Value	Meaning
`INITIAL_SNAKE_LENGTH`	20	Segments at spawn
`MAX_BODY_SEGMENTS`	400	Hard cap
`POINTS_PER_SEGMENT`	10	Score per +1 segment
`INITIAL_RADIUS`	14 px	Base thickness
`MAX_RADIUS`	30 px	Thickness cap
`RADIUS_GROWTH_INTERVAL`	30 segments	+1 radius every N

Score → Segments

segments = INITIAL_SNAKE_LENGTH + floor(score / POINTS_PER_SEGMENT)
segments = min(segments, MAX_BODY_SEGMENTS)

Segments → Radius

growth = floor(segments / RADIUS_GROWTH_INTERVAL)
radius = min(INITIAL_RADIUS + growth, MAX_RADIUS)

Boost Cost: Why I Use an Accumulator

My first attempt was score -= 15 * dt. Floating-point drift gave ugly decimal scores. I switched to an accumulator:

boostCostAccumulator += dt * BOOST_COST_PER_SECOND
if boostCostAccumulator >= 1:
    cost = floor(boostCostAccumulator)
    score = max(0, score - cost)
    boostCostAccumulator -= cost
    updateBody()

Now the score stays integer-clean.

7. Networking: The Compromises I Made for Client Prediction

Input Queue

The client sends inputs as fast as it wants. The server queues them:

snake.inputQueue.push({ angle, boosting })
while (input = snake.inputQueue.shift()) {
    snake.angle = input.angle;
    snake.isBoosting = input.boosting;
}

If two inputs arrive in the same tick window, the queue preserves order.

Lenient Food Validation

The client predicts eating food and hides it immediately. To avoid feeling laggy, I accept eat_food messages with a relaxed radius:

maxEatDist = snake.radius + food.size + 60   // +60 px leniency
if dist < maxEatDist:
    approve eat

That +60 is a deliberate anti-cheat compromise. Smooth gameplay beats strict validation in this genre.

Broadcast Throttling

Full state every tick would saturate bandwidth. I broadcast every 3rd tick (~50 ms, 20 Hz):

broadcastCounter++
if broadcastCounter % 3 === 0:
    room.broadcast(JSON.stringify({...}))

At 20 Hz with ~600 entities, payload is roughly 100–300 KB/s per client — comfortable for WebSocket.

Client-server message flow:

8. Performance Numbers

Metric	Configuration	Cost
Game tick	60 Hz fixed	—
Broadcast	20 Hz	—
Bot AI	20 Hz	500 bots × O(n) scan
Collision grid	200 px	O(n) average
Max players	100 + 500 bots	—
World	16,000 × 16,000	—
Trail resolution	2 px/step	~20K points max-length snake

9. One Week Later: What I Learned

The code works, but looking back there is plenty I would refactor:

Trail-based movement beats rigid-body chains. Simulate one head, look up the body from history. Zero physics glitches, tiny CPU cost. This is the design decision I'm happiest with.
Spatial hashing is non-negotiable. My first O(n²) brute-force version choked at 50 snakes. The grid dropped it to effectively linear.
The maxSteps cap saved the feel. Event-loop stalls are real. Cap at 3, swallow the time debt, never let snakes teleport.
Be lenient with clients. +60px eat radius, loose validation — players notice lag way more than they notice mild server-side forgiveness.
Dumb AI scales. 500 bots running A* would melt the CPU. Random wander + flee is indistinguishable to most players and costs nothing.

Deployment is one command: npx partykit deploy. Global edge nodes in seconds. If you want to ship a playable multiplayer game in a week, PartyKit removes a mountain of infrastructure work.

Want to try it yourself? Head over to Hi! Snake and see how long you can survive against 500 bots.

I Built an AirDrop Alternative That Lives Entirely Inside Your Browser

monkeymore studio — Thu, 07 May 2026 06:44:35 +0000

Ever tried to send a video from your phone to your laptop? The usual options are pretty terrible. You can upload it to WeChat or email, but then it gets compressed, sits on someone else's server, and takes forever if the file is large. Cloud storage works, but you need accounts, logins, and patience.

We wanted something simpler: open a web page, see your devices, send a file directly. No installs, no signups, no server touching your data. That's exactly what we built with Monkeymore Drop, and the entire thing runs inside your browser.

In this post, I'll walk you through how we pulled it off — the WebRTC tricks, the file chunking strategy, and why every file gets its own dedicated data channel.

Why Keep Everything in the Browser?

Before diving into the code, let's talk about why we insisted on a pure frontend implementation.

Your files never leave your network. When you use a traditional file sharing service, your data gets uploaded to a server somewhere, then downloaded again by the recipient. With our approach, the file travels directly from your browser to the other browser. The only thing a server does is help the two browsers find each other — like a digital introduction.

No installation required. It works on anything with a modern browser: iPhone, Android, Windows, Mac, Linux. Just open the URL and you're ready.

No compression or size limits. Since the data goes peer-to-peer, you're not fighting against upload quotas or watching your video get re-encoded into potato quality.

It works offline on LAN. As long as both devices are on the same WiFi, the transfer happens over your local network even if the internet is down.

The Big Picture

At a high level, the system has three moving parts:

A signaling server (WebSocket) — This just tells devices about each other. It never sees your files.
WebRTC peer connections — These create direct encrypted tunnels between browsers.
File transfer channels — Each file gets its own WebRTC data channel, so multiple files can fly in parallel.

Here's how the pieces fit together:

How the Peers Actually Connect

The trickiest part of WebRTC is that two browsers can't just call each other directly — they need to exchange "session descriptions" (SDP offers and answers) and ICE candidates (network addresses) first. That's where the WebSocket server comes in.

When you open the page, the browser connects to the signaling server and sends a join message:

// From src/useroom.ts
ws.current = new WebSocket("wss://dropshare.monkeymore.app/ws?name=" + name);

ws.current.onopen = () => {
  ws.current?.send(JSON.stringify({ type: "open", displayName: name }));
};

The server replies with your randomly generated name and a list of other peers in the same room. When a new peer shows up, you get a peer-joined event, and that's when the real magic starts.

The peer who receives the peer-joined message becomes the initiator — it creates a WebRTC offer:

// From src/webrtcpeer.ts
const peer = new SimplePeer({
  initiator: true,
  config: {
    iceServers: [
      { urls: "stun:stun1.l.google.com:19302" },
      { urls: "stun:global.stun.twilio.com:3478" },
      {
        urls: "turn:openrelay.metered.ca:80",
        username: "openrelayproject",
        credential: "openrelayproject",
      },
    ],
    iceTransportPolicy: "all",
  },
});

Notice those stun and turn servers. STUN helps a browser figure out its own public IP address behind a router. TURN is the fallback relay for when direct connection isn't possible (like when both sides are behind strict corporate firewalls). Without these, two devices on different networks would just stare at each other confused.

When the initiator's SimplePeer fires a signal event, it packages that up and sends it through the WebSocket to the other peer:

// From src/webrtcpeer.ts
peer.on("signal", (data) => {
  const message = JSON.stringify({
    type: "signal",
    to: peerId.id,
    roomType: peerId.roomType,
    roomId: peerId.roomId,
    data,
  });
  ws.send(message);
});

The other side receives this signal, feeds it to its own SimplePeer instance, and generates an answer. That answer gets sent back the same way. After a couple of ICE candidate exchanges, the browsers finally shake hands and the direct data channel opens.

Here's the full connection dance:

The Data Structures That Make It Work

We defined a few core types to keep the chaos organized. A peer isn't just an ID — it carries device info, room context, and methods to actually send things:

// From types/peer.ts
export type Peer = {
  id: string;
  ip: string;
  roomType: string;
  roomId: string;
  name: string;
  ua: {
    type: string;
    os: string;
    browser: string;
    deviceName: string;
    displayName: string;
  };
};

export type MonkeyDropPeer = Peer & {
  sendFiles: (files: FileWithId[]) => void;
  sendMessage: (messageId: string, message: string) => void;
  close: () => void;
};

And for tracking file transfers, we have a FileState object that lives in the React state:

// From types/peer.ts
export type FileState = {
  id: string;
  name: string;
  size: number;
  speed: number;
  percent: number;
  status: "NOT START" | "TRANSFERING" | "DONE";
  src?: string;
  file?: File;
  // For large files (> 5MB)
  totalChunks?: number;
  completedChunks?: number;
  chunkPercents?: number[];
  chunkBlobs?: Blob[];
};

The Messsage type wraps both text messages and file transfers so the chat UI can treat them uniformly:

// From types/peer.ts
export type Messsage = {
  type: "file" | "message";
  id: string;
  sendType: "send" | "receive";
  peerId: string;
  content: FileState | string;
};

Every File Gets Its Own Highway

Here's a design decision that might seem wasteful at first: instead of cramming all files through the single control data channel, we spin up a separate WebRTC peer connection for every single file.

Why? Two reasons:

Parallel transfers. If you drop five photos at once, they all transfer simultaneously instead of waiting in line.
Clean streaming. The control channel handles JSON messages and signal forwarding. Mixing binary file chunks with control messages would turn the stream into a mess.

The file channel's signals don't go through the WebSocket server — they get forwarded through the already-established control peer:

// From src/filetransfer.ts
peer.on("signal", (signal) => {
  // File channel signals go through the control peer, not WebSocket
  controlPeer.send(
    JSON.stringify({
      fileID: fileId,
      start: 0,
      signal,
    })
  );
});

And on the receiving side, the control peer listens for these forwarded signals and feeds them to the right file channel:

// From src/filetransfer.ts
controlPeer.addListener("data", (data) => {
  const dataJSON = JSON.parse(data);
  if (dataJSON.signal && dataJSON.fileID == fileId) {
    peer.signal(dataJSON.signal);
  }
});

Streaming Files with Backpressure

Once a file channel opens, we use Node.js-style streams to move the data without exploding memory. The sender side reads the file in chunks using filereader-stream, pipes it through a custom SendStream that adds protocol headers, and finally pipes it into the SimplePeer instance:

// From simple-peer-files/PeerFileSend.ts
const stream = read(this.file, {
  offset: this.offset,
  chunkSize: CHUNK_SIZE, // 64KB chunks
});

this.ss = new SendStream(this.file.size, this.offset);
stream.pipe(this.ss).pipe(this.peer);

The SendStream class extends Duplex and prepends a single-byte header to every chunk so the receiver knows what it's looking at:

// From simple-peer-files/PeerFileSend.ts
function pMsg(header: number, data: Uint8Array | null = null) {
  let resp: Uint8Array;
  if (data) {
    resp = new Uint8Array(1 + data.length);
    resp.set(data, 1);
  } else {
    resp = new Uint8Array(1);
  }
  resp[0] = header;
  return resp;
}

The headers are defined in Meta.ts:

// From simple-peer-files/Meta.ts
export const ControlHeaders = {
  FILE_START: 0,
  FILE_CHUNK: 1,
  FILE_CHUNK_ACK: 2,
  FILE_END: 3,
  TRANSFER_PAUSE: 4,
  TRANSFER_RESUME: 5,
  TRANSFER_CANCEL: 6,
};

On the receiving end, a ReceiveStream watches these headers, accumulates chunks, and emits a done event with a proper File object when everything arrives:

// From simple-peer-files/PeerFileReceive.ts
this.rs.on("chunk", (chunk) => {
  this.fileData.push(chunk);
  this.bytesReceived += chunk.byteLength;

  if (this.bytesReceived === this.fileSize) {
    this.sendPeer(ControlHeaders.FILE_END);
    const file = new window.File(this.fileData, this.fileName!, {
      type: this.fileType,
    });
    this.emit("done", file);
  }
});

The Chunking Strategy for Large Files

A single WebRTC data channel has throughput limits, and sending a 2GB file through one pipe is asking for trouble. We split anything larger than 5MB into chunks, each getting its own data channel, with up to 8 chunks in flight at once:

// From src/webrtcpeer.ts
const CHUNK_THRESHOLD = 5 * 1024 * 1024; // 5MB
const CHUNK_SIZE = 5 * 1024 * 1024;      // each chunk is 5MB
const MAX_CONCURRENT_CHUNKS = 8;         // max 8 parallel channels

The sender maintains a queue for each large file:

// From src/webrtcpeer.ts
const sendChunkQueues = {
  [fileId: string]: {
    file: File;
    totalChunks: number;
    chunks: { index: number; offset: number; length: number; done: boolean; started: boolean }[];
  };
};

When a chunk finishes, the scheduler grabs the next pending chunk and opens another channel:

// From src/webrtcpeer.ts
const startNextChunk = () => {
  const activeCount = queue.chunks.filter((c) => c.started && !c.done).length;
  if (activeCount >= MAX_CONCURRENT_CHUNKS) return;

  const pending = queue.chunks.find((c) => !c.started && !c.done);
  if (!pending) return;

  pending.started = true;
  const chunkId = `chunk:${f.id}:${pending.index}`;
  const chunkBlob = queue.file.slice(pending.offset, pending.offset + pending.length);
  // ... create channel and send
};

On the receiving side, useroom.ts collects chunks and merges them back together when everything lands:

// From src/useroom.ts
if (fs.completedChunks >= fs.totalChunks!) {
  const mergedBlob = new Blob(fs.chunkBlobs, { type: file.type });
  const mergedFile = new File([mergedBlob], fs.name, { type: file.type });
  fs.file = mergedFile;
  fs.percent = 100;
  fs.status = "DONE";
  fs.chunkBlobs = undefined; // free memory
}

Tracking Progress and Speed

Nobody likes a progress bar that lies. We track transfer speed by comparing bytes received over time:

// From src/filetransfer.ts
let lastStatus = { time: 0, bytesReceived: 0 };

pfr.on("progress", (percentage, bytesReceived) => {
  const now = Date.now();
  let speed;
  if (lastStatus.time > 0) {
    const elapsed = now - lastStatus.time;
    speed = Math.round((bytesReceived - lastStatus.bytesReceived) / elapsed);
  }
  lastStatus = { time: now, bytesReceived };
  ft(peerId, fileId, percentage, bytesReceived, speed);
});

For chunked files, useroom.ts computes an overall percentage by averaging individual chunk progress:

// From src/useroom.ts
if (!fs.chunkPercents) fs.chunkPercents = new Array(fs.totalChunks).fill(0);
fs.chunkPercents[chunkIndex] = progress;
fs.percent = Math.round(
  fs.chunkPercents.reduce((a, b) => a + b, 0) / fs.totalChunks!
);

The UI then renders this in real-time using a chat-style interface built on @chatui/core, showing file cards with progress bars and live speed readouts.

The Complete File Transfer Flow

Here's what happens from the moment you hit "send" to when the file lands on the other side:

What About the Room?

You might be wondering how devices find each other in the first place. The server groups peers by room. By default, devices with the same public IP get dropped into the same room automatically — handy for your home WiFi. We also support public rooms with shareable codes, so you can send files to a friend across the city.

The useRoom hook manages all of this. It holds the WebSocket reference, maintains the peer list, and wires up all the file transfer callbacks:

// From src/useroom.ts
export const useRoom = (name: string, roomId: string) => {
  const [peers, setPeers] = useState<MonkeyDropPeer[]>([]);
  const [messages, setMessages] = useState<Messsage[]>([]);
  const ws = useRef<WebSocket | null>(null);
  // ...
};

When the component unmounts or the user refreshes, it politely tells the server to disconnect:

// From src/useroom.ts
window.addEventListener("beforeunload", close);
window.addEventListener("pagehide", close); // for iOS Safari

const close = () => {
  if (ws.current) {
    ws.current.send(JSON.stringify({ type: "disconnect" }));
    ws.current.close();
  }
};

Wrapping Up

Building a browser-based file transfer tool isn't magic — it's just WebRTC, a bit of stream plumbing, and some careful state management. The key insight is that browsers are perfectly capable of speaking to each other directly. The only thing they need help with is the introduction.

If you're tired of compressing videos for email or waiting for cloud uploads, give it a try. Open Monkeymore Drop on two devices, and you'll see them pop up in the device list instantly. Select a file, hit send, and watch it travel directly from one browser to the other. No accounts, no uploads, no waiting.

How Emoji Mashups Work — And Why There's No "Algorithm" Behind Them

monkeymore studio — Mon, 27 Apr 2026 02:28:40 +0000

Ever wondered what happens when you smash 😂 and 🔥 together? You get a laughing face literally on fire. But here's the thing most people don't realize: Emoji Kitchen isn't doing real-time image processing. There's no AI model stitching stickers together on the fly, no Canvas API blending layers, no clever graphics algorithm running in your browser. The "magic" is actually a massive lookup table and a dead-simple frontend. Let me show you how this thing actually works under the hood.

The Big Surprise: It's Just a Really Big JSON File

When you open an Emoji Kitchen browser like Emoji Monkey, the very first thing it does is fetch a single JSON file — metadata.json — weighing in at a few megabytes. That file contains the entire universe of possible combinations. Every single mashup Google has ever drawn is already pre-defined in there.

The frontend doesn't generate anything. It doesn't blend images. It doesn't even know what the final sticker looks like until it loads a PNG from Google's CDN. All it knows is: "If the user picks emoji A and emoji B, the resulting image lives at this specific URL."

This is fundamentally different from how people imagine it works. You might picture some kind of procedural graphics system layering eyes onto faces or swapping colors in real time. Nope. Every single one of those 100,000+ combinations was hand-crafted by Google's design team. The code just looks up which ones exist.

Why Keep It Purely Frontend?

This architecture makes total sense once you think about it:

Zero server costs: You're not renting GPUs to run diffusion models or paying for image processing. You're serving a static JSON and some JavaScript.
Instant interaction: No round-trips to a backend mean selecting an emoji updates the UI in milliseconds.
Privacy by default: Nothing you search or select ever leaves your device. There's no analytics endpoint receiving your emoji preferences.
Offline-capable: Once that JSON is cached, the whole app works without internet (except for loading the actual PNG images).
Simple deployment: It's just a static site. Throw it on any CDN and it works globally.

The Data Structure That Powers Everything

The metadata.json deserialized into memory looks like this in TypeScript:

interface EmojiMetadata {
  knownSupportedEmoji: Array<string>;
  data: {
    [emojiCodepoint: string]: EmojiData;
  };
}

interface EmojiData {
  alt: string;
  keywords: Array<string>;
  emojiCodepoint: string;
  gBoardOrder: number;
  combinations: { 
    [otherEmojiCodepoint: string]: Array<EmojiCombination> 
  };
}

interface EmojiCombination {
  gStaticUrl: string;
  alt: string;
  leftEmoji: string;
  leftEmojiCodepoint: string;
  rightEmoji: string;
  rightEmojiCodepoint: string;
  date: string;
  isLatest: boolean;
  gBoardOrder: number;
}

This structure is elegant in its simplicity. knownSupportedEmoji is just an array of codepoints like 1f602 (😂) and 1f525 (🔥). The data map holds every emoji's details, and critically, its combinations field maps other emoji codepoints to an array of EmojiCombination objects.

Why an array for combinations? Because Google sometimes updates a design. The same pair might have an old version and a newer, better-drawn version. The isLatest flag lets the frontend pick the most current one.

Loading the Metadata

On app startup, this single function runs:

let emojiMetadata: EmojiMetadata | null = null;
let loadPromise: Promise<void> | null = null;

const METADATA_URL =
  "https://raw.githubusercontent.com/xsalazar/emoji-kitchen-backend/main/app/metadata.json";

export async function loadMetadata(): Promise<void> {
  if (emojiMetadata) return;
  if (loadPromise) return loadPromise;

  loadPromise = fetch(METADATA_URL)
    .then((res) => {
      if (!res.ok) throw new Error("Failed to load metadata");
      return res.json();
    })
    .then((data) => {
      emojiMetadata = data as EmojiMetadata;
    });

  return loadPromise;
}

Simple memoized fetch. If the metadata is already loaded, return immediately. If a fetch is in flight, wait for it. Otherwise, kick off the request. The app shows a loading spinner until this resolves.

The Lookup Flow: From Click to Sticker

Here's what happens when you actually use the app:

Notice how there's no "generation" step. The browser doesn't create the image — it just points an <img> tag to a URL Google already prepared.

Rendering the Left and Right Panels

The left panel shows every supported emoji:

export default function LeftEmojiList({
  handleLeftEmojiClicked,
  leftSearchResults,
  selectedLeftEmoji,
}) {
  var knownSupportedEmoji = getSupportedEmoji();

  if (leftSearchResults.length > 0) {
    knownSupportedEmoji = knownSupportedEmoji.filter((emoji) =>
      leftSearchResults.includes(emoji)
    );
  }

  return knownSupportedEmoji.map((emojiCodepoint) => {
    const data = getEmojiData(emojiCodepoint);
    return (
      <ImageListItem
        onClick={() => handleLeftEmojiClicked(emojiCodepoint)}
      >
        <img
          loading="lazy"
          width="32px"
          height="32px"
          alt={data.alt}
          src={getNotoEmojiUrl(emojiCodepoint)}
        />
      </ImageListItem>
    );
  });
}

The right panel is where the "combination logic" lives. When a left emoji is selected, the right panel checks the combinations map to know which emojis are valid partners:

export default function RightEmojiList({
  handleRightEmojiClicked,
  rightSearchResults,
  selectedLeftEmoji,
  selectedRightEmoji,
}) {
  var knownSupportedEmoji = getSupportedEmoji();
  var hasSelectedLeftEmoji = selectedLeftEmoji !== "";
  var possibleEmoji: Array<string> = [];

  if (hasSelectedLeftEmoji) {
    const data = getEmojiData(selectedLeftEmoji);
    possibleEmoji = Object.keys(data.combinations);
  }

  return knownSupportedEmoji.map((emojiCodepoint) => {
    var isValidCombo = true;
    if (hasSelectedLeftEmoji) {
      isValidCombo = possibleEmoji.includes(emojiCodepoint);
    }

    return (
      <ImageListItem
        onClick={() =>
          hasSelectedLeftEmoji && isValidCombo
            ? handleRightEmojiClicked(emojiCodepoint)
            : null
        }
        sx={{
          opacity: !hasSelectedLeftEmoji ? 0.1 : isValidCombo ? 1 : 0.1,
        }}
      >
        <img
          loading="lazy"
          width="32px"
          height="32px"
          alt={data.alt}
          src={getNotoEmojiUrl(emojiCodepoint)}
        />
      </ImageListItem>
    );
  });
}

This is the core "algorithm" in the entire app. If hasSelectedLeftEmoji is false, everything is dimmed to 10% opacity because nothing is selectable yet. Once you pick a left emoji, only emojis present in data.combinations become clickable. That's it.

Displaying the Final Mashup

When both emojis are selected, the app resolves the specific combination:

combination = getEmojiData(selectedLeftEmoji)
  .combinations[selectedRightEmoji]
  .filter((c) => c.isLatest)[0];

// Then renders:
<ImageListItem>
  <img alt={combination.alt} src={combination.gStaticUrl} />
</ImageListItem>

The gStaticUrl points to Google's image servers. An example URL looks something like https://www.gstatic.com/android/keyboard/emojikitchen/.../u1f602_u1f525.png. The browser fetches and displays it like any other image.

Search Without a Search Engine

The search feature is entirely client-side too. It debounces input at 300ms and filters against the alt text and keywords array stored in the metadata:

useEffect(() => {
  if (debouncedSearchTerm.trim().length >= 3) {
    const requestQuery = debouncedSearchTerm.trim().toLowerCase();
    const allEmoji = getSupportedEmoji();
    const results = allEmoji.filter((codepoint) => {
      const data = getEmojiData(codepoint);
      return (
        data.alt.toLowerCase().includes(requestQuery) ||
        data.keywords.some((k) => k.toLowerCase().includes(requestQuery))
      );
    });
    setSearchResults(results);
  } else {
    setSearchResults([]);
  }
}, [debouncedSearchTerm]);

No Algolia, no Elasticsearch, no backend API. Just Array.filter on an in-memory array. It's fast because even with thousands of emojis, modern JavaScript can filter arrays in microseconds.

Randomization: Just Picking from the Lookup Table

The "randomize" buttons aren't generating random combinations algorithmically. They're picking random entries from the existing data:

const handleFullEmojiRandomize = () => {
  const knownSupportedEmoji = getSupportedEmoji();
  const randomLeftEmoji =
    knownSupportedEmoji[
      Math.floor(Math.random() * knownSupportedEmoji.length)
    ];

  const data = getEmojiData(randomLeftEmoji);
  const possibleRightEmoji = Object.keys(data.combinations);

  const randomRightEmoji =
    possibleRightEmoji[
      Math.floor(Math.random() * possibleRightEmoji.length)
    ];

  setSelectedLeftEmoji(randomLeftEmoji);
  setSelectedRightEmoji(randomRightEmoji);
};

Pick a random left emoji, then pick a random key from its combinations object. That's the whole trick. Every "random" mashup is guaranteed to exist because it only picks from entries already in the JSON.

The Emoji Images: Noto Emoji SVGs

For displaying the individual emojis in the left and right lists (not the mashups), the app uses Google's open-source Noto Emoji font. It constructs a raw GitHub URL to fetch the SVG directly:

export function getNotoEmojiUrl(emojiCodepoint: string): string {
  return `https://raw.githubusercontent.com/googlefonts/noto-emoji/main/svg/emoji_u${emojiCodepoint
    .split("-")
    .filter((x) => x !== "fe0f")
    .map((x) => x.padStart(4, "0"))
    .join("_")}.svg`;
}

This strips out the variation selector (fe0f) and pads codepoints so a9 becomes 00a9 for consistency with Noto's filename convention. The result is a crisp SVG for every emoji in the picker.

What This Architecture Teaches Us

There's a common instinct among developers to reach for complex solutions: machine learning models, serverless functions, image processing pipelines. Emoji Kitchen is a great reminder that sometimes the best engineering is a well-structured lookup table.

Google's designers did the hard work — drawing 100,000+ unique stickers. The frontend's job is just to navigate that catalog efficiently. By pre-computing every possible output and shipping the index as JSON, you get:

Sub-millisecond "computation" (it's just a hash lookup)
Infinite scalability (static files on a CDN)
Zero maintenance for the combination logic
Perfect reproducibility (the same inputs always point to the same URL)

Try It Yourself

Browse the full catalog of over 100,000 emoji combinations at Emoji Monkey. Search for your favorites, find the weirdest mashups, and copy them straight to your clipboard — everything happens right in your browser, no data sent anywhere.

Grab Perfect Frames from Any Video Without Uploading

monkeymore studio — Fri, 24 Apr 2026 04:40:11 +0000

Ever needed a still image from a video? Maybe a funny reaction face, a product shot from a commercial, or a keyframe from a tutorial. Most people either take a blurry screenshot of their media player or resort to importing the entire video into editing software just to export one frame.

We built something faster. Upload a video, scrub to the moment you want, hit capture, and get five high-quality frames around that timestamp. Pick the best one, download it. No upload to a server, no bloated software, no guesswork about whether you paused at exactly the right moment.

Why Extract Frames in the Browser?

Taking screenshots from video should not require a full editing suite:

No upload: Your video stays on your machine. We never see it.
No quality loss: We extract frames at the video's native resolution, not your screen resolution.
Multiple options: Instead of one screenshot, we give you five frames around your target time. Pick the best one.
Format choice: PNG for editing, JPEG for sharing, WebP for the web.
Instant: No rendering, no queue, no waiting.

How It Works

Here is the full flow from upload to downloaded frame:

The Data Model

We track the video, the current playback position, and the extracted keyframes:

interface Keyframe {
  id: string;
  time: number;
  imageUrl: string;
}

interface VideoFile {
  id: string;
  file: File;
  previewUrl: string;
  duration: number;
  videoWidth: number;
  videoHeight: number;
}

Each keyframe stores its timestamp and a blob URL pointing to the captured image.

Two Ways to Extract Frames

We use a dual approach: Canvas API when possible, FFmpeg as a fallback.

Primary Method: Canvas API

If the browser can render the video, we draw frames directly to a canvas:

const captureWithCanvas = async (video: HTMLVideoElement) => {
  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');

  canvas.width = video.videoWidth || selectedFile!.videoWidth;
  canvas.height = video.videoHeight || selectedFile!.videoHeight;

  const offsets = [-1.5, -0.75, 0, 0.75, 1.5];
  const generatedFrames: Keyframe[] = [];
  const originalTime = video.currentTime;

  for (let i = 0; i < offsets.length; i++) {
    const offset = offsets[i];
    const frameTime = Math.max(0, Math.min(selectedFile!.duration, currentTime + offset));

    video.currentTime = frameTime;

    await new Promise<void>((resolve) => {
      const onSeeked = () => {
        video.removeEventListener('seeked', onSeeked);
        resolve();
      };
      video.addEventListener('seeked', onSeeked);
      setTimeout(() => {
        video.removeEventListener('seeked', onSeeked);
        resolve();
      }, 100);
    });

    ctx.drawImage(video, 0, 0, canvas.width, canvas.height);

    const mimeType = imageFormat === 'jpeg' ? 'image/jpeg' : 
                    imageFormat === 'png' ? 'image/png' : 'image/webp';
    const quality = imageFormat === 'png' ? undefined : 0.95;

    const supportsFormat = canvas.toDataURL(mimeType).indexOf(mimeType) > -1;
    const actualMimeType = supportsFormat ? mimeType : 'image/jpeg';

    const blob = await new Promise<Blob | null>((resolve) => {
      canvas.toBlob((b) => resolve(b), actualMimeType, quality);
    });

    if (blob) {
      const imageUrl = URL.createObjectURL(blob);
      generatedFrames.push({ id: `frame-${i}`, time: frameTime, imageUrl });
    }
  }

  video.currentTime = originalTime;
  generatedFrames.sort((a, b) => a.time - b.time);
  setKeyframes(generatedFrames);
};

A few things happening here:

We capture 5 frames around the current playback position: 1.5s before, 0.75s before, exactly at the timestamp, 0.75s after, and 1.5s after. This gives you options in case the exact frame you wanted was slightly off.
We wait for the seeked event after setting currentTime to ensure the video has actually loaded the frame before we draw it. A 100ms timeout acts as a fallback in case the event does not fire.
We check if the browser actually supports the requested image format. Some older browsers do not support WebP output from canvas, so we fall back to JPEG.
We restore the original playback position after capturing so the user is not disoriented.

Fallback Method: FFmpeg

Some video formats cannot be decoded by the browser's native player. In those cases, we fall back to FFmpeg:

const captureWithFFmpeg = async () => {
  const ffmpeg = ffmpegRef.current;
  const inputName = "input.mp4";

  const fileArrayBuffer = await selectedFile.file.arrayBuffer();
  await ffmpeg.writeFile(inputName, new Uint8Array(fileArrayBuffer));

  const offsets = [-1.5, -0.75, 0, 0.75, 1.5];
  const generatedFrames: Keyframe[] = [];

  for (let i = 0; i < offsets.length; i++) {
    const offset = offsets[i];
    const frameTime = Math.max(0, Math.min(selectedFile.duration, currentTime + offset));
    const outputName = `frame_${i}.jpg`;

    await ffmpeg.exec([
      "-ss", frameTime.toString(),
      "-i", inputName,
      "-vframes", "1",
      "-q:v", "2",
      "-pix_fmt", "rgb24",
      "-y",
      outputName
    ]);

    const data = await ffmpeg.readFile(outputName);

    if (data && data instanceof Uint8Array && data.length > 0) {
      let finalBlob: Blob;

      if (imageFormat === 'jpeg') {
        finalBlob = new Blob([data], { type: "image/jpeg" });
      } else {
        const img = new Image();
        const originalUrl = URL.createObjectURL(new Blob([data], { type: "image/jpeg" }));

        await new Promise<void>((resolve) => {
          img.onload = () => resolve();
          img.src = originalUrl;
        });

        const canvas = document.createElement('canvas');
        canvas.width = img.width;
        canvas.height = img.height;
        const ctx = canvas.getContext('2d');
        ctx?.drawImage(img, 0, 0);

        const mimeType = imageFormat === 'png' ? 'image/png' : 'image/webp';
        finalBlob = await new Promise<Blob>((resolve) => {
          canvas.toBlob((b) => resolve(b || new Blob()), mimeType, 0.95);
        });

        URL.revokeObjectURL(originalUrl);
      }

      const imageUrl = URL.createObjectURL(finalBlob);
      generatedFrames.push({ id: `frame-${i}`, time: frameTime, imageUrl });
    }

    await ffmpeg.deleteFile(outputName);
  }

  await ffmpeg.deleteFile(inputName);
  generatedFrames.sort((a, b) => a.time - b.time);
  setKeyframes(generatedFrames);
};

FFmpeg always outputs JPEG first. If the user requested PNG or WebP, we load the JPEG into an Image element, draw it to a canvas, and export in the desired format.

The FFmpeg command breaks down as:

-ss frameTime: Seek to the target timestamp
-vframes 1: Extract exactly one frame
-q:v 2: High quality (lower numbers are better for JPEG)
-pix_fmt rgb24: Full color output

Why Two Methods?

The Canvas API is faster and lighter — no need to load FFmpeg into memory. But some codecs (certain H.264 profiles, older formats) cannot be decoded by browsers. FFmpeg supports virtually everything, so it acts as a safety net.

We decide which method to use by checking the video element's state:

const canUseCanvas = video.videoWidth > 0 && video.videoHeight > 0 && video.readyState >= 2;

if (canUseCanvas) {
  await captureWithCanvas(video);
} else {
  await captureWithFFmpeg();
}

Pick Your Format

We offer three output formats:

PNG: Lossless, perfect for editing. Large file size.
JPEG: Compressed, great for sharing. Small file size.
WebP: Modern format with excellent compression. Not supported by all older software.

We default to PNG because screenshots are usually going into some kind of workflow where quality matters. But you can switch before capturing.

Navigating the Video

We provide arrow buttons to nudge the playback position by 1 second in either direction:

const seekVideo = (direction: "backward" | "forward") => {
  if (!videoRef.current) return;
  const step = direction === "backward" ? -1 : 1;
  videoRef.current.currentTime = Math.max(0, Math.min(
    selectedFile?.duration || 0,
    videoRef.current.currentTime + step
  ));
};

The current time updates in real time via the video's timeupdate event, so you always know exactly where you are.

Downloading Frames

You can download individual frames or grab all five at once:

const handleDownload = (frame: Keyframe) => {
  const link = document.createElement("a");
  link.href = frame.imageUrl;
  const extension = imageFormat === 'jpeg' ? 'jpg' : imageFormat;
  link.download = `screenshot_${formatTime(frame.time).replace(/[:.]/g, "-")}.${extension}`;
  document.body.appendChild(link);
  link.click();
  document.body.removeChild(link);
};

const handleDownloadAll = () => {
  keyframes.forEach((frame, index) => {
    setTimeout(() => {
      handleDownload(frame);
    }, index * 200);
  });
};

The 200ms stagger between downloads prevents browsers from blocking multiple simultaneous downloads as potential spam.

Filenames include the timestamp so you know exactly when each frame was captured:

screenshot_01-23-45.png
screenshot_01-24-15.png
screenshot_01-24-60.png

Video Error Handling

We handle playback errors gracefully:

onError={(e) => {
  const video = e.currentTarget;
  const errorCode = video.error?.code;
  let errorText = "Failed to load video";
  if (errorCode === 1) errorText = "Video loading aborted";
  else if (errorCode === 2) errorText = "Network error while loading video";
  else if (errorCode === 3) errorText = "Video decoding error - format may not be supported";
  else if (errorCode === 4) errorText = "Video format not supported by browser";
  setVideoError(errorText);
}}

If the browser cannot play the video, we show a helpful message and the FFmpeg fallback kicks in during capture.

Loading FFmpeg on Demand

// utils/ffmpegLoader.ts
import { fetchFile, toBlobURL } from "@ffmpeg/util";

let ffmpeg: any = null;
let fetchFileFn: any = null;

export async function loadFFmpeg() {
  if (ffmpeg) return { ffmpeg, fetchFile: fetchFileFn };

  const { FFmpeg } = await import("@ffmpeg/ffmpeg");

  ffmpeg = new FFmpeg();
  fetchFileFn = fetchFile;

  const baseURL = "https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.6/dist/umd";

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
  }, {
    corePath: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  });

  return { ffmpeg, fetchFile };
}

Cleanup

Frames are stored as blob URLs, which can accumulate memory:

const reset = useCallback(() => {
  if (selectedFile) {
    URL.revokeObjectURL(selectedFile.previewUrl);
  }
  keyframes.forEach(frame => {
    URL.revokeObjectURL(frame.imageUrl);
  });
  setSelectedFile(null);
  setCurrentTime(0);
  setKeyframes([]);
  setSelectedFrame(null);
  setError(null);
}, [selectedFile, keyframes]);

What We Learned

Building this tool revealed a few interesting challenges:

Canvas extraction is not instant: After setting video.currentTime, you have to wait for the seeked event before drawing. Without this, you capture the previous frame. The 100ms timeout fallback is essential because some browsers fire the event inconsistently.
Browser WebP support varies: We check canvas.toDataURL('image/webp') to see if the browser actually supports WebP output before trying to use it. Safari did not support WebP canvas export until relatively recently.
FFmpeg JPEG is the lowest common denominator: Since FFmpeg can always output JPEG, we use that as the intermediate format and convert to PNG/WebP via canvas. This avoids needing to compile extra encoders into FFmpeg.wasm.
Five frames is the sweet spot: We experimented with 3, 5, and 9 frames. Three felt like too few options. Nine was overwhelming. Five frames — spanning 3 seconds total — gives enough choice without clutter.
The crossOrigin="anonymous" attribute matters: Without it, some browsers throw security errors when trying to draw a locally-created video to a canvas. Even though the video comes from a local blob URL, the attribute signals that the operation is safe.

Give It a Try

Need a still image from a video? You can extract frames right now. No upload, no editing software, no quality loss.

👉 Video Screenshot Tool

Upload your video, scrub to the moment you want, pick your format, and capture. Your video never leaves your browser.

Strip the Sound from Any Video in Seconds

monkeymore studio — Fri, 24 Apr 2026 04:25:57 +0000

Sometimes you need a video without its soundtrack. Maybe the background music is copyrighted and you want to post it somewhere. Maybe there is unwanted conversation in the background of an otherwise perfect shot. Or maybe you just want the visuals without the noise.

Most video editing software makes you import the file, mute the audio track, and re-export the whole thing. That takes time and often re-encodes the video, subtly degrading quality. We built something simpler: a tool that removes the audio track and copies the video stream as-is. No re-encoding. No quality loss. Just a silent video file.

And it all happens in your browser.

Why Remove Audio Locally?

Removing audio is technically one of the easiest video operations. There is no reason to upload a 2GB file to a server just to delete its sound:

No upload needed: Your video stays on your disk the entire time.
No quality loss: We copy the video stream directly. Every pixel stays exactly the same.
Instant processing: Without re-encoding, the operation is essentially just file I/O.
Privacy: Nobody else hears your audio, even accidentally.
No weird limits: Files up to 2GB, limited only by your browser's memory.

How It Works

Here is the entire flow from upload to silent download:

The Data Model

We keep things simple with a single VideoFile object:

interface VideoFile {
  id: string;
  file: File;
  previewUrl: string;
  processedUrl?: string;
  processedFileName?: string;
  hasAudio?: boolean;
  error?: string;
  processing?: boolean;
  progress?: number;
  videoWidth?: number;
  videoHeight?: number;
  duration?: number;
}

The hasAudio field is tracked so we can show a helpful message if someone uploads a file that is already silent.

Pick Your Output Format

After uploading, you can choose the container format for your muted video:

const OUTPUT_FORMATS = [
  { value: "mp4", label: "MP4", extension: "mp4", mimeType: "video/mp4" },
  { value: "webm", label: "WebM", extension: "webm", mimeType: "video/webm" },
  { value: "mov", label: "MOV", extension: "mov", mimeType: "video/quicktime" },
  { value: "avi", label: "AVI", extension: "avi", mimeType: "video/x-msvideo" },
];

MP4 is the default because it works everywhere. But if you need a different container for compatibility or workflow reasons, you can switch before processing.

The Core Command: Two Flags That Do All the Work

The actual audio removal is almost comically simple:

const ffmpegArgs = [
  "-i", inputName,
  "-c:v", "copy",
  "-an",
  "-y",
  outputName
];

await ffmpeg.exec(ffmpegArgs);

That is it. Two flags:

-c:v copy: Copies the video stream without re-encoding. Every frame stays exactly as it was in the original file.
-an: Disables audio. This tells FFmpeg to not include any audio tracks in the output.

The result is a video file that contains only the video stream, with zero audio data.

Why `-c:v copy` Matters

Without this flag, FFmpeg would re-encode the video using its default settings. That means:

Longer processing time
Potential quality loss
Different file size

With -c:v copy, FFmpeg simply reads the compressed video data from the input and writes it directly to the output. The video quality is bit-for-bit identical to the original. Processing time is measured in seconds, not minutes.

The Full Processing Logic

Here is the complete removeAudio function:

const removeAudio = async () => {
  if (!selectedFile || !ffmpegRef.current) return;

  setIsProcessing(true);
  setError(null);
  setSelectedFile(prev => prev ? { ...prev, processing: true, progress: 0, error: undefined } : null);

  try {
    const ffmpeg = ffmpegRef.current;
    const inputExt = selectedFile.file.name.split('.').pop() || 'mp4';
    const inputName = `input.${inputExt}`;
    const outputName = `output_muted.${outputFormat}`;

    const fileArrayBuffer = await selectedFile.file.arrayBuffer();
    await ffmpeg.writeFile(inputName, new Uint8Array(fileArrayBuffer));

    const ffmpegArgs = [
      "-i", inputName,
      "-c:v", "copy",
      "-an",
      "-y",
      outputName
    ];

    await ffmpeg.exec(ffmpegArgs);

    let data: any;
    try {
      data = await ffmpeg.readFile(outputName);
    } catch (readErr) {
      throw new Error("Failed to read output file");
    }

    if (!data || (data instanceof Uint8Array && data.length === 0)) {
      throw new Error("Output file is empty");
    }

    const uint8Data = data instanceof Uint8Array ? data : new Uint8Array();
    const buffer = new ArrayBuffer(uint8Data.length);
    new Uint8Array(buffer).set(uint8Data);

    const outputFormatInfo = OUTPUT_FORMATS.find(f => f.value === outputFormat);
    const blob = new Blob([buffer], { type: outputFormatInfo?.mimeType || "video/mp4" });
    const processedUrl = URL.createObjectURL(blob);
    const baseName = selectedFile.file.name.replace(/\.[^/.]+$/, "");

    setSelectedFile(prev => prev ? {
      ...prev,
      processedUrl,
      processedFileName: `${baseName}_muted.${outputFormatInfo?.extension || outputFormat}`,
      processing: false,
      progress: 100,
    } : null);

    await ffmpeg.deleteFile(inputName);
    await ffmpeg.deleteFile(outputName);
  } catch (err: any) {
    console.error("Processing error:", err);
    setError("Failed to remove audio from video");
    setSelectedFile(prev => prev ? { ...prev, error: "Processing failed", processing: false } : null);
  } finally {
    setIsProcessing(false);
  }
};

A few defensive touches worth noting:

We handle both Uint8Array and string responses from ffmpeg.readFile(), just in case.
We validate that the output file is not empty before presenting it to the user.
The output Blob gets the correct MIME type so browsers handle previews and downloads properly.

Loading FFmpeg on Demand

As with all our tools, FFmpeg loads lazily:

// utils/ffmpegLoader.ts
import { fetchFile, toBlobURL } from "@ffmpeg/util";

let ffmpeg: any = null;
let fetchFileFn: any = null;

export async function loadFFmpeg() {
  if (ffmpeg) return { ffmpeg, fetchFile: fetchFileFn };

  const { FFmpeg } = await import("@ffmpeg/ffmpeg");

  ffmpeg = new FFmpeg();
  fetchFileFn = fetchFile;

  const baseURL = "https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.6/dist/umd";

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
  }, {
    corePath: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  });

  return { ffmpeg, fetchFile };
}

Dynamic import keeps the initial bundle lean. Blob URLs avoid CORS headaches. Caching the instance means subsequent operations start faster.

Preview the Result

After processing, we show the muted video with a built-in player so you can verify it is actually silent:

{selectedFile.processedUrl && (
  <div className="bg-green-50 dark:bg-green-900/20 rounded-lg p-4">
    <div className="flex items-center gap-3 mb-4">
      <VolumeX className="w-8 h-8 text-green-600" />
      <div>
        <h3 className="font-medium text-green-800">Audio Removed Successfully!</h3>
        <p className="text-sm text-green-600">{selectedFile.processedFileName}</p>
      </div>
    </div>

    <div className="bg-gray-100 dark:bg-gray-800 rounded-lg overflow-hidden">
      <video src={selectedFile.processedUrl} controls className="w-full max-h-64 mx-auto" />
    </div>

    <p className="text-sm text-gray-500 mt-2 text-center">
      Preview: This video should have no sound
    </p>
  </div>
)}

The "Preview: This video should have no sound" text is a small but important UX touch. It sets the right expectation — if the user hears something, they know something went wrong.

Cleanup

We clean up object URLs and virtual filesystem entries:

const reset = useCallback(() => {
  if (selectedFile) {
    URL.revokeObjectURL(selectedFile.previewUrl);
    if (selectedFile.processedUrl) URL.revokeObjectURL(selectedFile.processedUrl);
  }
  setSelectedFile(null);
  setError(null);
  setOutputFormat("mp4");
}, [selectedFile]);

And after each operation:

await ffmpeg.deleteFile(inputName);
await ffmpeg.deleteFile(outputName);

What We Learned

This was one of the simpler tools to build, but it still taught us a few things:

-an is surprisingly final: Unlike muting in a video editor, -an actually removes the audio track entirely. The output file contains zero audio data. This makes the file slightly smaller and ensures there is absolutely no risk of accidental sound leakage.
Container conversion happens for free: Because we are copying the video stream, changing the output container (e.g., MP4 to MOV) is trivial. FFmpeg just repackages the same video data into a different file format.
-c:v copy does not always work: If the source video uses a codec that is not compatible with the target container, the copy will fail. For example, a VP8 video inside a WebM container cannot be directly copied into an MP4 container because MP4 does not natively support VP8. In practice, most user-uploaded videos are H.264, which works in all our supported containers.
Users want confirmation: We added the "This video should have no sound" preview message because early testers were unsure whether the tool had actually worked. Visual confirmation that the audio was gone turned out to be more important than we expected.

Give It a Try

Got a video with audio you want gone? Strip it out right now. No upload, no account, no waiting.

👉 Remove Audio from Video

Upload your video, pick your format, and download the silent version. The video quality stays exactly the same — only the sound disappears.

Stitch Multiple Videos Together Without Re-encoding Them

monkeymore studio — Fri, 24 Apr 2026 04:21:22 +0000

Ever recorded several short clips and wished you could just glue them into one file? Maybe a bunch of vacation footage, a series of screen recordings, or several takes of the same scene. Most video editors make you import everything, drag clips onto a timeline, render the whole thing, and wait. That is overkill when all you want is to put file A before file B.

We built a video merger that runs entirely in your browser. Upload your clips, drag them into the right order, hit merge, and download a single continuous video. The best part? Since all your clips are already in the same format, we do not re-encode anything. We just concatenate them. That means no quality loss and lightning-fast processing.

Why Merge Videos in the Browser?

Traditional video editing software is powerful but heavy. For simple concatenation, it is like using a chainsaw to cut a sandwich:

No upload queue: Your clips stay on your machine. No waiting for a server to process them.
No quality loss: We use FFmpeg's concat demuxer with stream copying. The video and audio streams are copied as-is, frame for frame.
Instant reordering: Drag clips around in the list to change the order. No timeline, no layers, no keyframes.
Privacy: Your footage never leaves your device.
Actually fast: Because we are not re-encoding, merging is mostly just file I/O. Even several large clips process quickly.

The catch? This tool is specifically for joining videos that are already compatible — same resolution, same codec, same frame rate. If you try to merge a 1080p clip with a 720p clip, FFmpeg will complain. For those cases, you need a full re-encode, which our tool does not do by design.

How It Works

Here is the full flow from upload to merged download:

The Data Model

Instead of a single file, we manage a list of segments:

interface VideoSegment {
  id: string;
  file: File;
  previewUrl: string;
  duration: number;
  videoWidth: number;
  videoHeight: number;
}

Each segment stores its own preview URL and metadata. The list order determines the final merge order.

Uploading and Validating Multiple Files

We support both clicking to select files and drag-and-drop. Importantly, we allow multiple files at once:

const addVideos = async (files: FileList | null) => {
  if (!files || files.length === 0) return;

  const validTypes = ["video/mp4", "video/webm", "video/quicktime", "video/x-msvideo", "video/ogg"];
  const maxSize = 500 * 1024 * 1024;
  const newSegments: VideoSegment[] = [];

  for (const file of Array.from(files)) {
    if (!validTypes.includes(file.type)) {
      setError("Please select valid video files (MP4, WebM, MOV, AVI)");
      continue;
    }

    if (file.size > maxSize) {
      setError("Video file is too large. Maximum size is 500MB.");
      continue;
    }

    const info = await validateVideo(file);
    if (info) {
      newSegments.push({
        id: `${file.name}-${Date.now()}-${Math.random()}`,
        file,
        previewUrl: info.previewUrl!,
        duration: info.duration!,
        videoWidth: info.videoWidth!,
        videoHeight: info.videoHeight!,
      });
    }
  }

  if (newSegments.length > 0) {
    setSegments(prev => [...prev, ...newSegments]);
    setError(null);
  }
};

The validateVideo helper reads metadata without loading the entire file:

const validateVideo = async (file: File): Promise<Partial<VideoSegment> | null> => {
  return new Promise((resolve) => {
    const videoUrl = URL.createObjectURL(file);
    const video = document.createElement("video");
    video.preload = "metadata";
    video.onloadedmetadata = () => {
      resolve({
        duration: video.duration,
        videoWidth: video.videoWidth,
        videoHeight: video.videoHeight,
        previewUrl: videoUrl,
      });
    };
    video.onerror = () => {
      resolve(null);
    };
    video.src = videoUrl;
  });
};

This creates a hidden video element, loads just the metadata, and extracts duration and dimensions. Invalid files are silently skipped.

Reordering with Drag and Drop

The video list supports native HTML5 drag and drop:

const handleDragStart = (index: number) => {
  setDraggedIndex(index);
};

const handleDragOverItem = (e: React.DragEvent, index: number) => {
  e.preventDefault();
  if (draggedIndex === null || draggedIndex === index) return;

  moveSegment(draggedIndex, index);
  setDraggedIndex(index);
};

const moveSegment = (fromIndex: number, toIndex: number) => {
  if (toIndex < 0 || toIndex >= segments.length) return;

  setSegments(prev => {
    const newSegments = [...prev];
    const [removed] = newSegments.splice(fromIndex, 1);
    newSegments.splice(toIndex, 0, removed);
    return newSegments;
  });
};

For users who prefer precision over dragging, we also provide up and down arrow buttons on each item. The list shows a running total duration so you know exactly how long the final video will be.

The Concatenation Trick: No Re-encoding

This is where things get interesting. Most people assume merging videos requires re-encoding everything. It does not — if the videos are compatible.

We use FFmpeg's concat demuxer:

const mergeVideos = async () => {
  if (segments.length < 2 || !ffmpegRef.current) return;

  setIsProcessing(true);
  setError(null);
  setProgress(0);

  try {
    const ffmpeg = ffmpegRef.current;
    const segmentFiles: string[] = [];

    // Write all input files
    for (let i = 0; i < segments.length; i++) {
      const segment = segments[i];
      const inputName = `input_${i}.mp4`;
      segmentFiles.push(inputName);

      const fileArrayBuffer = await segment.file.arrayBuffer();
      await ffmpeg.writeFile(inputName, new Uint8Array(fileArrayBuffer));
    }

    // Create concat file list
    const concatList = segmentFiles.map(f => `file '${f}'`).join("\n");
    await ffmpeg.writeFile("concat_list.txt", concatList);

    // Concatenate segments
    const outputName = "output.mp4";
    await ffmpeg.exec([
      "-f", "concat",
      "-safe", "0",
      "-i", "concat_list.txt",
      "-c", "copy",
      "-y",
      outputName
    ]);

    // Read output file
    const data = await ffmpeg.readFile(outputName);
    const uint8Data = data instanceof Uint8Array ? data : new Uint8Array();
    const buffer = new ArrayBuffer(uint8Data.length);
    new Uint8Array(buffer).set(uint8Data);
    const blob = new Blob([buffer], { type: "video/mp4" });
    const url = URL.createObjectURL(blob);

    setOutputUrl(url);
    setOutputFileName(`merged_${Date.now()}.mp4`);

    // Cleanup
    for (const segmentFile of segmentFiles) {
      try {
        await ffmpeg.deleteFile(segmentFile);
      } catch (e) {
        console.log("Failed to delete segment file:", segmentFile);
      }
    }

    try {
      await ffmpeg.deleteFile("concat_list.txt");
      await ffmpeg.deleteFile(outputName);
    } catch (e) {
      console.log("Failed to delete temp files");
    }
  } catch (err) {
    console.error("Merge error:", err);
    setError("Failed to merge videos");
  } finally {
    setIsProcessing(false);
  }
};

Let us break down why this works:

-f concat: Tells FFmpeg to use the concatenation demuxer instead of treating the input as a single video.
-safe 0: Allows file paths in the concat list that do not follow strict naming rules. Without this, FFmpeg might reject files with spaces or special characters.
-i concat_list.txt: The input is a text file listing all the videos to join, in order.
-c copy: Copies the video and audio streams without re-encoding. This preserves original quality and runs much faster than transcoding.

The concat list file looks like this:

file 'input_0.mp4'
file 'input_1.mp4'
file 'input_2.mp4'

Why `-c copy` Is So Fast

When you re-encode a video, FFmpeg has to decode every frame, process it, and encode it again. That is CPU-intensive and slow. With -c copy, FFmpeg simply reads the compressed data from each input file and writes it sequentially into the output file. No decompression, no recompression. The operation is bounded by disk I/O speed, not CPU power.

For a set of 5-minute clips at 1080p, a full re-encode might take 10-15 minutes. With stream copying, it takes seconds.

The Compatibility Requirement

The trade-off is that all input videos must share the same:

Video codec (e.g., all H.264)
Audio codec (e.g., all AAC)
Resolution
Frame rate

If you try to merge a 1080p clip with a 720p clip, FFmpeg will fail with an error about incompatible streams. This is by design — the concat demuxer is not a transcoder. For our use case, this is actually a feature. Most people merging videos shot them on the same device with the same settings, so compatibility is guaranteed.

Loading FFmpeg on Demand

As always, we load FFmpeg lazily:

// utils/ffmpegLoader.ts
import { fetchFile, toBlobURL } from "@ffmpeg/util";

let ffmpeg: any = null;
let fetchFileFn: any = null;

export async function loadFFmpeg() {
  if (ffmpeg) return { ffmpeg, fetchFile: fetchFileFn };

  const { FFmpeg } = await import("@ffmpeg/ffmpeg");

  ffmpeg = new FFmpeg();
  fetchFileFn = fetchFile;

  const baseURL = "https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.6/dist/umd";

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
  }, {
    corePath: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  });

  return { ffmpeg, fetchFile };
}

Dynamic import keeps the initial page load snappy. Blob URLs sidestep CORS issues. Caching the instance avoids paying the startup cost on subsequent uses.

Progress Tracking

Even with -c copy, progress events fire as FFmpeg works through the files:

ffmpeg.on("progress", ({ progress }: { progress: number }) => {
  setProgress(Math.round(progress * 100));
});

This gives users feedback that something is actually happening, which is important when processing multiple large files.

Cleanup

We are careful about memory management. Each segment has its own preview URL, and the output has another:

const reset = () => {
  segments.forEach(segment => {
    URL.revokeObjectURL(segment.previewUrl);
  });
  if (outputUrl) {
    URL.revokeObjectURL(outputUrl);
  }
  setSegments([]);
  setOutputUrl(null);
  setProgress(0);
  setError(null);
};

And after merging, we delete the temporary files from FFmpeg's virtual filesystem:

for (const segmentFile of segmentFiles) {
  try {
    await ffmpeg.deleteFile(segmentFile);
  } catch (e) {
    console.log("Failed to delete segment file:", segmentFile);
  }
}

What We Learned

Building a video merger taught us a few things:

The concat demuxer is surprisingly picky: If one file has a different codec profile or audio sample rate, the whole merge fails. We initially tried to catch and normalize these differences, but that requires re-encoding — which defeats the purpose. Instead, we let FFmpeg fail and show a clear error.
Drag and drop reordering feels magical: Users love being able to drag clips around to change the order. It is one of those UI patterns that seems obvious in retrospect but makes the tool feel significantly more polished.
-safe 0 is essential: Without it, FFmpeg rejects concat list entries that contain spaces, hyphens, or other characters commonly found in filenames. This caused mysterious failures until we added the flag.
Preview URLs add up: Each uploaded video gets an object URL for its thumbnail. With 20+ clips, that is a lot of memory. The reset function revokes all of them at once.
Concatenation is not the same as blending: Some users expect transitions between clips. Our tool does hard cuts only — the concat demuxer does not support fades, cross-dissolves, or any effects. For that, you need a real video editor.

Give It a Try

Got a bunch of clips that need to become one video? You can merge them right now. No upload, no rendering queue, no quality loss.

👉 Video Merger

Upload your clips, drag them into order, and download the merged result. Everything happens on your machine — your videos never leave your browser.

Rip Audio Out of Any Video Without Uploading It

monkeymore studio — Fri, 24 Apr 2026 04:15:22 +0000

Found a great soundtrack buried inside a YouTube rip? Need the voiceover from a screen recording as a standalone file? Or maybe you just want to turn a music video into an MP3 for your playlist. Extracting audio from video is one of those tasks that sounds trivial until you actually need to do it.

Most tools force you to upload the entire video first. That is slow, wastes bandwidth, and feels ridiculous when all you want is the sound. We built an audio extractor that runs entirely in your browser. Drop a video in, pick your format, and download the audio track. The video file never leaves your machine.

Why Do Audio Extraction in the Browser?

Audio extraction is actually a perfect fit for client-side processing:

No upload needed: Why send a 500MB video to a server just to strip out a 5MB audio track?
Instant start: No queue, no waiting behind other users' jobs.
Privacy: Your video stays local. We never see it, hear it, or store it.
Pick your format: MP3 for compatibility, WAV for editing, FLAC for archiving — you choose.
Works offline: Once FFmpeg.wasm is cached, you can extract audio without an internet connection.

The only real limit is your device's memory. But since we are only dealing with the audio stream, even large videos process surprisingly fast.

The Full Flow

Here is what happens from upload to audio download:

The Data Model

We track the video file and whether it actually has an audio stream:

interface VideoFile {
  id: string;
  file: File;
  previewUrl: string;
  audioUrl?: string;
  audioFileName?: string;
  hasAudio?: boolean;
  audioCodec?: string;
  error?: string;
  processing?: boolean;
  progress?: number;
  videoWidth?: number;
  videoHeight?: number;
  duration?: number;
}

The hasAudio field matters because not every video file actually contains an audio track. Screen recordings without mic input, raw camera footage, and certain downloaded clips might be video-only. We handle that gracefully instead of throwing a cryptic error.

Five Audio Formats, Five Different Strategies

We support the formats people actually use:

const AUDIO_FORMATS = [
  { value: "mp3", label: "MP3", extension: "mp3", mimeType: "audio/mpeg" },
  { value: "aac", label: "AAC", extension: "aac", mimeType: "audio/aac" },
  { value: "wav", label: "WAV", extension: "wav", mimeType: "audio/wav" },
  { value: "ogg", label: "OGG", extension: "ogg", mimeType: "audio/ogg" },
  { value: "flac", label: "FLAC", extension: "flac", mimeType: "audio/flac" },
];

Each format gets its own encoder settings because one-size-fits-all does not work for audio.

MP3: The Universal Format

case "mp3":
  ffmpegArgs = [
    "-i", inputName,
    "-vn",
    "-c:a", "libmp3lame",
    "-q:a", "2",
    "-y",
    outputName
  ];
  break;

libmp3lame: The standard MP3 encoder. Works everywhere.
-q:a 2: Variable bitrate mode, high quality (0 is best, 9 is worst). Level 2 strikes a good balance — roughly 190-250 kbps, which is transparent for most content.
-vn: Disables video. This is the key flag that tells FFmpeg to extract only the audio stream.

AAC: The Efficiency King

case "aac":
  ffmpegArgs = [
    "-i", inputName,
    "-vn",
    "-c:a", "aac",
    "-b:a", "192k",
    "-y",
    outputName
  ];
  break;

AAC at 192 kbps generally sounds better than MP3 at the same bitrate. It is the format used by Apple Music, YouTube, and most streaming services. If you want small files without noticeable quality loss, AAC is the way to go.

WAV: The Editor's Choice

case "wav":
  ffmpegArgs = [
    "-i", inputName,
    "-vn",
    "-c:a", "pcm_s16le",
    "-ar", "44100",
    "-ac", "2",
    "-y",
    outputName
  ];
  break;

pcm_s16le: Uncompressed 16-bit PCM audio. No quality loss whatsoever.
-ar 44100: Standard CD sample rate.
-ac 2: Stereo output.

WAV files are huge but perfect for importing into DAWs, video editors, or any situation where you need pristine audio quality.

OGG: The Open Source Option

case "ogg":
  ffmpegArgs = [
    "-i", inputName,
    "-vn",
    "-c:a", "libvorbis",
    "-q:a", "4",
    "-y",
    outputName
  ];
  break;

OGG Vorbis is royalty-free and offers excellent compression. Quality level 4 is roughly equivalent to 128-160 kbps MP3 but typically sounds better.

FLAC: The Archivist's Format

case "flac":
  ffmpegArgs = [
    "-i", inputName,
    "-vn",
    "-c:a", "flac",
    "-y",
    outputName
  ];
  break;

FLAC is lossless compression — you get the exact same audio data as WAV, but the file is typically 40-60% smaller. Perfect for archiving music or audio you might need to transcode later.

Detecting Silent Videos

Not every video has audio. We handle this in two ways:

First, we try to detect audio tracks when loading the video metadata using browser APIs:

video.onloadedmetadata = () => {
  const hasAudio = (video as any).mozHasAudio !== false || 
                   Boolean((video as any).webkitAudioDecodedByteCount) ||
                   Boolean((video as any).audioTracks?.length);

  setSelectedFile({
    id: `${file.name}-${Date.now()}`,
    file,
    previewUrl: videoUrl,
    videoWidth: video.videoWidth,
    videoHeight: video.videoHeight,
    duration: video.duration,
    hasAudio: undefined,
  });
};

But browser detection is unreliable across different formats. So we also catch FFmpeg errors and translate them into a friendly message:

try {
  await ffmpeg.exec(ffmpegArgs);
} catch (execErr: any) {
  const errorMessage = String(execErr);

  if (errorMessage.includes("Stream map") || 
      errorMessage.includes("does not contain") ||
      errorMessage.includes("No audio") ||
      errorMessage.includes("Output file #0 does not contain any stream")) {
    throw new Error("NO_AUDIO_STREAM");
  }

  throw new Error(`FFmpeg execution failed: ${errorMessage}`);
}

And after reading the output, we sanity-check the file size:

if (uint8Data.length < 100) {
  throw new Error("NO_AUDIO_STREAM");
}

A legitimate audio file should never be under 100 bytes. If it is, something went wrong — usually because the source video had no audio to extract.

When we detect a silent video, we show a clear error state instead of a generic failure message:

if (err.message === "NO_AUDIO_STREAM") {
  setError("This video file does not contain an audio stream");
  setSelectedFile(prev => prev ? { 
    ...prev, 
    error: "NO_AUDIO_STREAM", 
    hasAudio: false,
    processing: false 
  } : null);
}

The UI then shows a friendly "No Audio Detected" screen with a button to try another video.

Preview Before Download

After extraction, we embed a native HTML5 audio player so users can preview the result before downloading:

{selectedFile.audioUrl && (
  <div className="bg-green-50 dark:bg-green-900/20 rounded-lg p-4">
    <div className="flex items-center gap-3 mb-4">
      <Music className="w-8 h-8 text-green-600" />
      <div>
        <h3 className="font-medium text-green-800">Audio Extraction Complete!</h3>
        <p className="text-sm text-green-600">{selectedFile.audioFileName}</p>
      </div>
    </div>
    <audio src={selectedFile.audioUrl} controls className="w-full" />
  </div>
)}

This is a small touch but it saves users from downloading a file, realizing it sounds wrong, and starting over.

Loading FFmpeg on Demand

As with all our tools, FFmpeg loads lazily:

// utils/ffmpegLoader.ts
import { fetchFile, toBlobURL } from "@ffmpeg/util";

let ffmpeg: any = null;
let fetchFileFn: any = null;

export async function loadFFmpeg() {
  if (ffmpeg) return { ffmpeg, fetchFile: fetchFileFn };

  const { FFmpeg } = await import("@ffmpeg/ffmpeg");

  ffmpeg = new FFmpeg();
  fetchFileFn = fetchFile;

  const baseURL = "https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.6/dist/umd";

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
  }, {
    corePath: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  });

  return { ffmpeg, fetchFile };
}

Dynamic import keeps the initial bundle small. Blob URLs avoid CORS issues. Caching the instance means subsequent extractions start faster.

Progress and Cleanup

We track FFmpeg progress:

ffmpeg.on("progress", ({ progress }: { progress: number }) => {
  setSelectedFile(prev => prev ? { ...prev, progress: Math.round(progress * 100) } : null);
});

And clean up properly:

const reset = useCallback(() => {
  if (selectedFile) {
    URL.revokeObjectURL(selectedFile.previewUrl);
    if (selectedFile.audioUrl) URL.revokeObjectURL(selectedFile.audioUrl);
  }
  setSelectedFile(null);
  setError(null);
  setAudioFormat("mp3");
}, [selectedFile]);

Plus filesystem cleanup after each extraction:

await ffmpeg.deleteFile(inputName);
await ffmpeg.deleteFile(outputName);

What We Learned

Building this tool revealed a few interesting edge cases:

Not all videos have audio: We assumed every video had at least an audio stream. Nope. Screen recordings without system audio, certain camera formats, and some downloaded clips are video-only. Catching the "NO_AUDIO_STREAM" case gracefully was essential.
Browser audio detection is unreliable: mozHasAudio, webkitAudioDecodedByteCount, and audioTracks all exist on different browsers with different behaviors. We use all three as hints, but the real check is whether FFmpeg can actually extract something.
MP3 quality levels are confusing: -q:a 0 through -q:a 9 is the LAME VBR scale, but it is inverted — 0 is best, 9 is worst. We picked level 2 as the default because it is roughly equivalent to 256 kbps VBR, which is transparent for virtually all content.
WAV files are surprisingly large: A 3-minute WAV extracted from a video can easily hit 30MB. Users sometimes expect the audio file to be tiny. We added the format descriptions to set expectations — WAV is uncompressed, FLAC is lossless compression, MP3/OGG/AAC are lossy compression.
-vn is your friend: This single flag disables video processing entirely. Without it, FFmpeg might try to re-encode the video stream even when you only want audio, making extraction take ten times longer.

Give It a Try

Got a video with a soundtrack you want to save? Or a voiceover you need as a separate file? You can extract it right now.

👉 Extract Audio from Video

Upload your video, pick your format, preview the result, and download. MP3, AAC, WAV, OGG, or FLAC — your choice. Your video never leaves your browser.

Crop Videos in Your Browser With a Visual Drag-and-Drop Box

monkeymore studio — Fri, 24 Apr 2026 04:03:22 +0000

Ever recorded something and realized there is a weird reflection in the corner? Or shot a landscape video that needs to become a vertical TikTok? Cropping sounds simple — until you realize most online tools make you guess pixel coordinates or upload your file to who-knows-where.

We built something different. A video cropper that shows you exactly what you are cutting. Drag a box over your video, resize the corners, pick a preset ratio if you want, and hit go. Your video never leaves your browser.

Why Do This Locally?

Video cropping is oddly personal. You are deciding what stays in the frame and what gets thrown away. Sending that footage to a server feels unnecessary:

Visual feedback: See the crop area in real time instead of typing x: 120, y: 80 into a form and hoping for the best.
No upload delay: A 500MB video takes forever to upload just to shave 100 pixels off the edge.
Privacy: Your footage stays on your machine. We never see it.
Instant results: No queue, no processing estimate, no refreshing the page.
Touch-friendly: Works on tablets and phones, not just desktops with a mouse.

The limitation is the same as all browser-based video tools — very long or very high-res videos can eat a lot of RAM. But for typical clips, it is perfectly fine.

How the Whole Thing Works

Here is the flow from upload to cropped download:

The Data Model

We track the crop area separately from the video file:

interface CropArea {
  x: number;
  y: number;
  width: number;
  height: number;
}

interface VideoFile {
  id: string;
  file: File;
  previewUrl: string;
  outputUrl?: string;
  outputFileName?: string;
  error?: string;
  processing?: boolean;
  progress?: number;
  duration: number;
  videoWidth: number;
  videoHeight: number;
}

The CropArea stores coordinates in the video's native pixel space, not screen pixels. That is important because the video might be displayed at 800px wide on screen while its actual resolution is 1920px wide. We do the coordinate conversion so the crop is precise.

The Interactive Crop Box

This is where most of the code lives. We render a semi-transparent overlay on top of the video that users can drag and resize.

Mouse Interaction

type DragMode = 'move' | 'resize-nw' | 'resize-ne' | 'resize-sw' | 'resize-se' | null;

When you click inside the crop box, it moves. When you click one of the four corner handles, it resizes from that corner. We figure out which mode you are in by checking where you clicked relative to the crop area:

const handleMouseDown = (e: React.MouseEvent) => {
  const pos = getMousePosition(e.clientX, e.clientY);
  const handleSize = 12 / calculateDisplayScale();

  const isResizeNW = pos.x >= cropArea.x && pos.x <= cropArea.x + handleSize && 
                     pos.y >= cropArea.y && pos.y <= cropArea.y + handleSize;
  const isResizeNE = pos.x >= cropArea.x + cropArea.width - handleSize && pos.x <= cropArea.x + cropArea.width && 
                     pos.y >= cropArea.y && pos.y <= cropArea.y + handleSize;
  // ... similar for SW and SE

  if (isResizeNW) setDragMode('resize-nw');
  else if (isResizeNE) setDragMode('resize-ne');
  // ... etc
  else if (pos.x >= cropArea.x && pos.x <= cropArea.x + cropArea.width &&
           pos.y >= cropArea.y && pos.y <= cropArea.y + cropArea.height) {
    setDragMode('move');
  }
};

The getMousePosition helper converts screen coordinates back to video pixel coordinates by accounting for the display scale:

const getMousePosition = (clientX: number, clientY: number) => {
  const rect = videoContainerRef.current.getBoundingClientRect();
  const scale = calculateDisplayScale();
  return {
    x: (clientX - rect.left) / scale,
    y: (clientY - rect.top) / scale
  };
};

Moving the Crop Area

When dragging in move mode, we clamp the position so the crop box never leaves the video boundaries:

if (dragMode === 'move') {
  newCropArea.x = Math.max(0, Math.min(
    selectedFile.videoWidth - cropArea.width,
    dragStart.cropX + deltaX
  ));
  newCropArea.y = Math.max(0, Math.min(
    selectedFile.videoHeight - cropArea.height,
    dragStart.cropY + deltaY
  ));
}

Resizing from Corners

Resizing is trickier because dragging a corner changes both position and size. For example, dragging the northwest corner moves the top-left position while also changing the width and height:

if (dragMode.includes('e')) {
  newCropArea.width = Math.max(minSize, Math.min(
    selectedFile.videoWidth - cropArea.x,
    dragStart.cropW + deltaX
  ));
}
if (dragMode.includes('w')) {
  const newWidth = Math.max(minSize, Math.min(
    dragStart.cropW - deltaX,
    dragStart.cropX + dragStart.cropW
  ));
  const widthDiff = newCropArea.width - newWidth;
  newCropArea.width = newWidth;
  newCropArea.x = Math.max(0, cropArea.x + widthDiff);
}

The minimum size is clamped to 50 pixels so users do not accidentally shrink the crop box to nothing.

Touch Support

We also support touch devices, though touch interaction is simplified to just moving the crop box (no corner resizing on touch, to avoid accidentally triggering browser gestures):

const handleTouchStart = (e: React.TouchEvent) => {
  const touch = e.touches[0];
  const pos = getMousePosition(touch.clientX, touch.clientY);

  if (pos.x >= cropArea.x && pos.x <= cropArea.x + cropArea.width &&
      pos.y >= cropArea.y && pos.y <= cropArea.y + cropArea.height) {
    setDragMode('move');
    setDragStart({ x: pos.x, y: pos.y, cropX: cropArea.x, cropY: cropArea.y, ... });
    setIsDragging(true);
  }
};

Aspect Ratio Presets

For common use cases, we offer one-click presets:

[
  { label: "16:9", w: 1920, h: 1080 },
  { label: "4:3",  w: 1280, h: 960  },
  { label: "1:1",  w: 1080, h: 1080 },
  { label: "9:16", w: 1080, h: 1920 },
]

Clicking a preset fills in the width and height fields, then the crop box is centered on the video. If the preset dimensions are larger than the source video, we clamp them to fit. This makes it trivial to turn a landscape video into a square for Instagram or a vertical for TikTok.

The FFmpeg Crop: More Than Just Coordinates

Once the user is happy with the crop area, we hand it off to FFmpeg. But it is not as simple as passing the raw coordinates. Video encoding has quirks.

The Even-Number Problem

H.264 video typically uses the yuv420p pixel format, which requires both width and height to be divisible by 2. Odd dimensions cause encoding failures. So we sanitize the crop values:

let safeX = Math.max(0, Math.min(maxWidth - 2, Math.round(cropArea.x)));
let safeY = Math.max(0, Math.min(maxHeight - 2, Math.round(cropArea.y)));
let safeWidth = Math.max(2, Math.min(maxWidth - safeX, Math.round(cropArea.width)));
let safeHeight = Math.max(2, Math.min(maxHeight - safeY, Math.round(cropArea.height)));

// Make dimensions even (required for yuv420p)
safeWidth = Math.floor(safeWidth / 2) * 2;
safeHeight = Math.floor(safeHeight / 2) * 2;
safeX = Math.floor(safeX / 2) * 2;
safeY = Math.floor(safeY / 2) * 2;

// Re-validate after making even
if (safeX + safeWidth > maxWidth) {
  safeWidth = Math.floor((maxWidth - safeX) / 2) * 2;
}
if (safeY + safeHeight > maxHeight) {
  safeHeight = Math.floor((maxHeight - safeY) / 2) * 2;
}

This rounds every dimension down to the nearest even number, then re-checks that the crop area still fits inside the video bounds. Without this step, FFmpeg throws cryptic errors about invalid arguments.

The FFmpeg Command

const cropFilter = `crop=${safeWidth}:${safeHeight}:${safeX}:${safeY}`;

await ffmpeg.exec([
  "-i", inputName,
  "-vf", cropFilter,
  "-c:v", "libx264",
  "-preset", "ultrafast",
  "-profile:v", "baseline",
  "-level", "3.0",
  "-pix_fmt", "yuv420p",
  "-movflags", "+faststart",
  "-an",
  "-y",
  outputName
]);

Breaking this down:

-vf crop=w:h:x:y: The actual crop filter. Cuts out a rectangle from the source.
-c:v libx264: Encode the output as H.264.
-preset ultrafast: Prioritize speed over file size. Since we are only cropping, users want it done quickly.
-profile:v baseline -level 3.0: Use the most compatible H.264 profile. This ensures the output plays on older devices and browsers.
-pix_fmt yuv420p: Standard pixel format. Required for broad compatibility.
-movflags +faststart: Reorganize the MP4 so playback can start before the entire file downloads.
-an: Drop the audio. This is a crop tool — the audio stream would be identical anyway, and stripping it simplifies the output.

Handling Different Data Types

FFmpeg.wasm sometimes returns a string instead of a Uint8Array, so we handle both:

let uint8Data: Uint8Array;
if (data instanceof Uint8Array) {
  uint8Data = data;
} else if (typeof data === 'string') {
  uint8Data = new TextEncoder().encode(data);
} else {
  throw new Error(`Unexpected data type: ${typeof data}`);
}

This defensive coding prevents mysterious failures when the underlying library behavior varies.

Loading FFmpeg on Demand

As always, we load FFmpeg lazily:

// utils/ffmpegLoader.ts
import { fetchFile, toBlobURL } from "@ffmpeg/util";

let ffmpeg: any = null;
let fetchFileFn: any = null;

export async function loadFFmpeg() {
  if (ffmpeg) return { ffmpeg, fetchFile: fetchFileFn };

  const { FFmpeg } = await import("@ffmpeg/ffmpeg");

  ffmpeg = new FFmpeg();
  fetchFileFn = fetchFile;

  const baseURL = "https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.6/dist/umd";

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
  }, {
    corePath: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  });

  return { ffmpeg, fetchFile };
}

Dynamic import keeps the initial bundle small. Blob URLs avoid CORS issues. And caching the instance means you do not pay the startup tax twice.

Progress and Cleanup

We track FFmpeg progress:

ffmpeg.on("progress", ({ progress }: { progress: number }) => {
  setSelectedFile(prev => prev ? { ...prev, progress: Math.round(progress * 100) } : null);
});

And clean up after ourselves:

const reset = useCallback(() => {
  if (selectedFile) {
    URL.revokeObjectURL(selectedFile.previewUrl);
    if (selectedFile.outputUrl) URL.revokeObjectURL(selectedFile.outputUrl);
  }
  setSelectedFile(null);
  setCropWidth("");
  setCropHeight("");
  setCropArea({ x: 0, y: 0, width: 0, height: 0 });
  setError(null);
}, [selectedFile]);

Plus filesystem cleanup after each crop:

await ffmpeg.deleteFile(inputName);
await ffmpeg.deleteFile(outputName);

Error Handling

We catch and translate FFmpeg errors into human-readable messages:

if (errorMessage.includes("crop") || errorMessage.includes("Invalid argument")) {
  setError("Invalid crop dimensions. Please try different crop settings.");
} else if (errorMessage.includes("Failed to inject frame")) {
  setError("Failed to apply crop filter. The crop area may be invalid.");
} else if (errorMessage.includes("empty") || errorMessage.includes("failed to create")) {
  setError("Video processing failed. The crop area may extend beyond video boundaries or the video format is not supported.");
} else {
  setError("Failed to crop video. Please try again.");
}

Even if processing fails, we attempt cleanup so the virtual filesystem does not get cluttered with half-finished files.

What We Learned

Building an interactive cropper in the browser taught us a few things:

Coordinate math is deceptively tricky: Converting between screen pixels, video pixels, and scaled display pixels sounds easy until you start dealing with resize handles. Getting the northwest corner to drag correctly — moving both position and size in opposite directions — took more debugging than expected.
yuv420p even-dimension requirements are non-negotiable: We spent a while chasing "Invalid argument" errors from FFmpeg before realizing the pixel format requires even widths and heights. Now we round everything down to the nearest even number before passing it to FFmpeg.
Baseline profile is worth it: We started with the default H.264 profile, and some mobile browsers refused to play the output. Switching to baseline profile fixed compatibility across the board.
-an simplifies everything: We initially tried to preserve audio during cropping, but it complicated the command and caused codec compatibility issues. Since cropping does not change the audio at all, stripping it and letting users recombine later if needed turned out to be the cleanest approach.
Touch and mouse need different UX: Resize handles work great with a mouse but are nearly impossible to grab accurately on a touchscreen. We simplified touch interaction to just moving the crop box, which feels natural on phones and tablets.

Give It a Try

Got a video with something you want to cut out of the frame? Or need to reframe a landscape clip for vertical social media? You can crop it right now — visually, with instant feedback.

👉 Video Crop Tool

Upload your video, drag the crop box, pick a preset if you want, and download the result. Your footage never leaves your browser.

Convert Videos to Multiple Formats Without Leaving Your Browser

monkeymore studio — Fri, 24 Apr 2026 03:55:28 +0000

Need an MP4 to work in Premiere? A WebM for your website? An AVI because some ancient tool you are stuck with only accepts that? Format conversion is one of those things that sounds simple until you actually try to do it.

Most online converters follow the same tired playbook: upload your video, wait in a queue, download the result, and hope they did not watermark it or sell your data. We got tired of that dance. So we built a converter that runs entirely in your browser. Your video never leaves your machine, and you get to pick exactly what comes out the other side.

Why Bother Doing This Locally?

Uploading a video just to change its file extension feels ridiculous. Here is why keeping it in the browser actually matters:

No upload bottleneck: A 400MB video can take 20 minutes to upload on a slow connection. Skip that entirely.
Privacy by default: Your footage stays on your disk. We do not see it, store it, or process it on our end.
No weird limits: 500MB max file size because that is what browsers can reasonably handle, not because we want you to upgrade.
Instant start: No queue, no "estimated wait time," no refreshing the page to check if it is done.
Actually free: You are using your own CPU, so there is no server bill to pass on to you.

The trade-off is that very long or very high-resolution videos can push your browser's memory limits. But for typical clips — a few minutes at 1080p — it works without breaking a sweat.

How It All Works

Here is the full journey from dropping a file to downloading the converted version:

The Data Model

We keep everything in a single VideoFile object:

interface VideoFile {
  id: string;
  file: File;
  previewUrl: string;
  convertedUrl?: string;
  convertedFileName?: string;
  error?: string;
  processing?: boolean;
  progress?: number;
  videoWidth?: number;
  videoHeight?: number;
  duration?: number;
}

Nothing fancy — just enough to track the original upload, the conversion progress, and the final result.

Pick Your Poison: Five Output Formats

Different formats exist for different reasons. We support the ones people actually need:

const OUTPUT_FORMATS = [
  { value: "mp4", label: "MP4", extension: "mp4", mimeType: "video/mp4" },
  { value: "webm", label: "WebM", extension: "webm", mimeType: "video/webm" },
  { value: "mov", label: "MOV", extension: "mov", mimeType: "video/quicktime" },
  { value: "avi", label: "AVI", extension: "avi", mimeType: "video/x-msvideo" },
  { value: "mkv", label: "MKV", extension: "mkv", mimeType: "video/x-matroska" },
];

Each format gets a tailored encoding strategy because one-size-fits-all usually means one-size-fits-none.

MP4, MOV, and MKV: The H.264 Family

These three formats all use the same underlying codec stack because they are the modern standard:

case "mp4":
case "mov":
case "mkv":
  ffmpegArgs.push(
    "-c:v", "libx264",
    "-preset", "ultrafast",
    "-crf", "28",
    "-c:a", "aac",
    "-b:a", "128k",
    "-movflags", "+faststart"
  );
  break;

libx264: The most compatible video encoder on the planet. Works everywhere.
-preset ultrafast: We prioritize speed over compression efficiency. Since this is a format converter, not a compressor, users care more about getting their file quickly than squeezing every last byte.
-crf 28: A reasonable quality target. Good enough for most use cases without bloating the file.
-movflags +faststart: Reorganizes the MP4/MOV so playback can start before the entire file is downloaded. Essential if someone wants to preview the result in their browser.

WebM: The Web-Native Choice

WebM is fantastic for websites because it streams well and has great browser support. But it needs different codecs:

case "webm":
  ffmpegArgs.push(
    "-c:v", "libvpx",
    "-b:v", "1M",
    "-c:a", "libvorbis",
    "-q:a", "4"
  );
  break;

libvpx: VP8 video encoding. Widely supported and royalty-free.
libvorbis: The audio codec that traditionally pairs with VP8 in WebM.
-b:v 1M: A fixed video bitrate of 1 Mbps. WebM is often used for web delivery, so a predictable bitrate helps with bandwidth planning.

AVI: The Legacy Fallback

AVI is old, clunky, and still somehow required by a surprising number of tools:

case "avi":
  ffmpegArgs.push(
    "-c:v", "mpeg4",
    "-b:v", "800k",
    "-c:a", "aac",
    "-b:a", "128k"
  );
  break;

mpeg4: Simple MPEG-4 Part 2 video. Widely supported by AVI players.
aac: Modern audio codec that most AVI parsers can handle these days.

The Core Conversion Logic

Here is the full convertVideo function that ties everything together:

const convertVideo = async () => {
  if (!selectedFile || !ffmpegRef.current) return;

  setIsConverting(true);
  setSelectedFile(prev => prev ? { ...prev, processing: true, progress: 0 } : null);

  try {
    const ffmpeg = ffmpegRef.current;
    const inputExt = selectedFile.file.name.split('.').pop() || 'mp4';
    const inputName = `input.${inputExt}`;
    const outputName = `output.${outputFormat}`;

    const fileArrayBuffer = await selectedFile.file.arrayBuffer();
    await ffmpeg.writeFile(inputName, new Uint8Array(fileArrayBuffer));

    const ffmpegArgs = ["-i", inputName];

    switch (outputFormat) {
      case "mp4":
      case "mov":
      case "mkv":
        ffmpegArgs.push(
          "-c:v", "libx264",
          "-preset", "ultrafast",
          "-crf", "28",
          "-c:a", "aac",
          "-b:a", "128k",
          "-movflags", "+faststart"
        );
        break;
      case "webm":
        ffmpegArgs.push(
          "-c:v", "libvpx",
          "-b:v", "1M",
          "-c:a", "libvorbis",
          "-q:a", "4"
        );
        break;
      case "avi":
        ffmpegArgs.push(
          "-c:v", "mpeg4",
          "-b:v", "800k",
          "-c:a", "aac",
          "-b:a", "128k"
        );
        break;
      default:
        ffmpegArgs.push("-c", "copy");
    }

    ffmpegArgs.push("-y", outputName);
    await ffmpeg.exec(ffmpegArgs);

    const data = await ffmpeg.readFile(outputName);
    const uint8Data = data instanceof Uint8Array ? data : new Uint8Array();
    const buffer = new ArrayBuffer(uint8Data.length);
    new Uint8Array(buffer).set(uint8Data);

    const outputFormatInfo = OUTPUT_FORMATS.find(f => f.value === outputFormat);
    const blob = new Blob([buffer], { type: outputFormatInfo?.mimeType || "video/mp4" });
    const convertedUrl = URL.createObjectURL(blob);
    const baseName = selectedFile.file.name.replace(/\.[^/.]+$/, "");

    setSelectedFile(prev => prev ? {
      ...prev,
      convertedUrl,
      convertedFileName: `${baseName}.${outputFormatInfo?.extension || outputFormat}`,
      processing: false,
      progress: 100,
    } : null);

    await ffmpeg.deleteFile(inputName);
    await ffmpeg.deleteFile(outputName);
  } catch (err) {
    setError("Failed to convert video");
    setSelectedFile(prev => prev ? { ...prev, error: "Conversion failed", processing: false } : null);
  } finally {
    setIsConverting(false);
  }
};

A few things worth noting:

We preserve the original file extension for the input name so FFmpeg can infer the container format correctly.
The output Blob gets the correct MIME type so browsers handle it properly when downloading or previewing.
We always clean up the virtual filesystem after conversion. Those in-memory files add up fast.

Why Not Just Use `-c copy`?

You might wonder why we do not just use stream copying (-c copy) for all formats. After all, if you are converting MP4 to MOV, the underlying H.264 video and AAC audio are already compatible.

The answer is simple: container compatibility. MP4 and MOV are very similar, but AVI and WebM have strict requirements about which codecs they support. An H.264 stream copied directly into an AVI container might not play in older players. A WebM container flat-out rejects anything that is not VP8/VP9 or Vorbis/Opus.

So we re-encode to the target format's "native" codecs. It takes a bit longer than a straight copy, but the result actually works wherever you take it.

Loading FFmpeg Without Blocking the Page

FFmpeg.wasm is heavy — several megabytes of JavaScript and WebAssembly. We load it on demand:

// utils/ffmpegLoader.ts
import { fetchFile, toBlobURL } from "@ffmpeg/util";

let ffmpeg: any = null;
let fetchFileFn: any = null;

export async function loadFFmpeg() {
  if (ffmpeg) return { ffmpeg, fetchFile: fetchFileFn };

  const { FFmpeg } = await import("@ffmpeg/ffmpeg");

  ffmpeg = new FFmpeg();
  fetchFileFn = fetchFile;

  const baseURL = "https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.6/dist/umd";

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
  }, {
    corePath: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  });

  return { ffmpeg, fetchFile };
}

The dynamic import keeps the initial bundle lean. toBlobURL turns CDN resources into local blob URLs, avoiding CORS headaches. And caching the instance means you do not pay the startup cost twice if you convert multiple videos.

Progress Tracking

Nobody likes a frozen UI. FFmpeg.wasm emits progress events:

ffmpeg.on("progress", ({ progress }: { progress: number }) => {
  setSelectedFile(prev => prev ? { ...prev, progress: Math.round(progress * 100) } : null);
});

This drives a progress bar that actually moves, which makes the wait feel significantly shorter.

Cleanup

Object URLs and virtual filesystem entries both leak memory if you forget them:

const reset = useCallback(() => {
  if (selectedFile) {
    URL.revokeObjectURL(selectedFile.previewUrl);
    if (selectedFile.convertedUrl) URL.revokeObjectURL(selectedFile.convertedUrl);
  }
  setSelectedFile(null);
  setError(null);
}, [selectedFile]);

And after each conversion:

await ffmpeg.deleteFile(inputName);
await ffmpeg.deleteFile(outputName);

Without this, repeated conversions would eventually hit the browser's memory ceiling.

What We Learned

Building this taught us a few things:

Container formats are picky: We initially tried -c copy for everything. It worked for MP4-to-MOV but spectacularly failed for MP4-to-AVI and MP4-to-WebM. Each container has its own codec whitelist, and respecting that is non-negotiable.
-preset ultrafast is the right call for converters: When people convert formats, they usually want speed. They are not trying to win a compression contest. Ultrafast trades a slightly larger file size for dramatically faster encoding.
MIME types matter for Blob URLs: If you create a Blob with the wrong MIME type, the browser might refuse to play or download it correctly. We map each output format to its proper type so the resulting file behaves normally.
WebM with libvpx is slow: VP8 encoding is noticeably slower than H.264. We warn users implicitly through the progress bar — WebM conversions just take longer, and that is the cost of using a royalty-free codec.

Give It a Spin

Got a video in the wrong format? You can convert it right now. No upload, no account, no waiting.

👉 Video Converter

Just drag your video in, pick the output format, and download the result. MP4, WebM, MOV, AVI, MKV — all processed locally in your browser.

Shrink Your Videos Without Sending Them Anywhere

monkeymore studio — Fri, 24 Apr 2026 03:47:38 +0000

Ever tried to email a video and watched your mail client laugh at you? Or upload a clip to a messaging app only to see it compressed into a pixelated mess? Video files get big fast — a minute of 1080p footage can easily eat up 100MB.

Most online compressors make you upload the entire file first. That is slow, eats your bandwidth, and who knows what happens to your data on the other side. We wanted something better: a tool that crunches video files down to size while keeping them on your machine the whole time.

So we built a browser-based video compressor using FFmpeg.wasm. Drop a 500MB video in, pick your settings, and download a smaller version. No upload. No queue. No server snooping on your footage.

Why Compress Video in the Browser?

If you are going to reduce a file's size, the last thing you want is to add a 200MB upload to the process. Here is why client-side compression makes sense:

Skip the upload entirely: Your video stays on your disk. We never see it.
No file size gatekeeping: Most online tools cap you at 100MB or force a paid plan. We handle files up to 2GB because the limit is your device's memory, not our server budget.
You control the quality: Many services use mystery settings that turn your crisp video into soup. Here you pick exactly how aggressive the compression is.
No waiting in line: Server-side tools queue your job behind everyone else's. Browser compression starts immediately.
Zero infrastructure cost for us: Your CPU does the work, so we don't need a render farm to stay afloat.

The downside? Very large or very long videos can strain your RAM. But for typical clips — a few minutes at 1080p or less — it works great.

The Full Flow

Here is what happens from drag-and-drop to download:

The Data Model

We keep the state in a single VideoFile object that tracks everything from the original upload to the compressed result:

interface VideoFile {
  id: string;
  file: File;
  previewUrl: string;
  compressedUrl?: string;
  compressedFileName?: string;
  compressedSize?: number;
  error?: string;
  processing?: boolean;
  progress?: number;
  videoWidth?: number;
  videoHeight?: number;
  duration?: number;
  bitrate?: number;
}

The compressedSize field is what lets us show the satisfying "You saved X%" number at the end.

Three Compression Presets (Plus a Custom Mode)

Not everyone knows what a CRF value is, so we offer three one-click presets:

const COMPRESSION_PRESETS = [
  { 
    value: "high", 
    label: "High Quality", 
    videoBitrate: "2M", 
    audioBitrate: "128k",
    crf: "23",
    scale: -1 
  },
  { 
    value: "medium", 
    label: "Medium Quality", 
    videoBitrate: "1M", 
    audioBitrate: "96k",
    crf: "28",
    scale: -2 
  },
  { 
    value: "low", 
    label: "Low Quality", 
    videoBitrate: "500k", 
    audioBitrate: "64k",
    crf: "35",
    scale: -2 
  },
];

High Quality (crf 23): Barely noticeable quality loss. Good for archiving or sharing where fidelity matters.
Medium Quality (crf 28): The sweet spot. Significantly smaller files with acceptable quality. This is our default.
Low Quality (crf 35): Aggressive compression. Great for drafts, previews, or situations where file size is the only thing that matters.

Each preset also sets a maximum bitrate cap and an audio bitrate, so you don't end up with a tiny video and a bloated audio track.

For power users, there is a custom bitrate mode where you can type exactly what you want:

const [customBitrate, setCustomBitrate] = useState<string>("");
const [useCustomSettings, setUseCustomSettings] = useState(false);

Enter 800k for 800 kbps, 2M for 2 Mbps, whatever fits your needs.

Resizing While We Compress

Sometimes you don't just want a smaller file — you want a smaller resolution. We offer five options:

const RESOLUTION_OPTIONS = [
  { value: "original", label: "Original", scale: -1 },
  { value: "1080p", label: "1080p", scale: 1080 },
  { value: "720p", label: "720p", scale: 720 },
  { value: "480p", label: "480p", scale: 480 },
  { value: "360p", label: "360p", scale: 360 },
];

When you pick anything other than "Original," we add a scale filter to the FFmpeg command. The -2 in scale=-2:720 tells FFmpeg to scale the height to 720px and automatically calculate the width while keeping the aspect ratio — and ensuring it is divisible by 2, which H.264 requires.

Building the FFmpeg Command

The actual compression logic assembles the command piece by piece based on user choices:

const compressVideo = async () => {
  if (!selectedFile || !ffmpegRef.current) return;

  setIsCompressing(true);
  setSelectedFile(prev => prev ? { ...prev, processing: true, progress: 0 } : null);

  try {
    const ffmpeg = ffmpegRef.current;
    const inputExt = selectedFile.file.name.split('.').pop() || 'mp4';
    const inputName = `input.${inputExt}`;
    const outputName = `output_compressed.mp4`;

    const fileArrayBuffer = await selectedFile.file.arrayBuffer();
    await ffmpeg.writeFile(inputName, new Uint8Array(fileArrayBuffer));

    const ffmpegArgs = ["-i", inputName];
    const preset = COMPRESSION_PRESETS.find(p => p.value === compressionPreset);
    const resolution = RESOLUTION_OPTIONS.find(r => r.value === targetResolution);

    ffmpegArgs.push("-c:v", "libx264");

    if (resolution && resolution.scale > 0) {
      ffmpegArgs.push("-vf", `scale=-2:${resolution.scale}`);
    }

    if (useCustomSettings && customBitrate) {
      ffmpegArgs.push("-b:v", customBitrate);
      ffmpegArgs.push("-maxrate", customBitrate);
      ffmpegArgs.push("-bufsize", `${parseInt(customBitrate) * 2}k`);
    } else if (preset) {
      ffmpegArgs.push("-crf", preset.crf);
      ffmpegArgs.push("-preset", "medium");
      ffmpegArgs.push("-maxrate", preset.videoBitrate);
      ffmpegArgs.push("-bufsize", `${parseInt(preset.videoBitrate) * 2}k`);
    }

    ffmpegArgs.push("-c:a", "aac");
    if (preset) {
      ffmpegArgs.push("-b:a", preset.audioBitrate);
    }

    ffmpegArgs.push("-movflags", "+faststart");
    ffmpegArgs.push("-y", outputName);

    await ffmpeg.exec(ffmpegArgs);

    const data = await ffmpeg.readFile(outputName);
    const uint8Data = data instanceof Uint8Array ? data : new Uint8Array();
    const buffer = new ArrayBuffer(uint8Data.length);
    new Uint8Array(buffer).set(uint8Data);
    const blob = new Blob([buffer], { type: "video/mp4" });
    const compressedUrl = URL.createObjectURL(blob);
    const baseName = selectedFile.file.name.replace(/\.[^/.]+$/, "");

    setSelectedFile(prev => prev ? {
      ...prev,
      compressedUrl,
      compressedFileName: `${baseName}_compressed.mp4`,
      compressedSize: blob.size,
      processing: false,
      progress: 100,
    } : null);

    await ffmpeg.deleteFile(inputName);
    await ffmpeg.deleteFile(outputName);
  } catch (err) {
    setError("Failed to compress video");
    setSelectedFile(prev => prev ? { ...prev, error: "Compression failed", processing: false } : null);
  } finally {
    setIsCompressing(false);
  }
};

Let us break down what those flags actually do:

-c:v libx264: The gold standard for video encoding. H.264 works everywhere.
-crf 28: Constant Rate Factor — lower means better quality but bigger files. 28 is our default sweet spot.
-preset medium: A balance between encoding speed and compression efficiency.
-maxrate 1M + -bufsize 2M: Caps the bitrate so the file does not unexpectedly balloon. The bufsize is double the maxrate for smooth rate control.
-c:a aac -b:a 96k: Re-encodes audio to AAC at 96 kbps. Small but decent quality.
-movflags +faststart: Reorganizes the MP4 so it starts playing before the entire file downloads. Essential for web playback.

The Quality-Size Trade-Off in Numbers

The savings vary wildly depending on your source material, but here is a rough idea:

Source	Preset	Typical Savings
1080p screen recording	Medium	60-80%
4K camera footage	High	30-50%
Already-compressed MP4	Low	10-30%
High-motion gameplay	Medium	40-60%

Screen recordings compress beautifully because they have lots of static areas. Already-compressed videos do not shrink as much because there is less redundancy to exploit.

Showing the Results

After compression, we show a before-and-after card:

const calculateSavings = () => {
  if (!selectedFile?.compressedSize) return 0;
  const originalSize = selectedFile.file.size;
  const compressedSize = selectedFile.compressedSize;
  const savings = ((originalSize - compressedSize) / originalSize) * 100;
  return Math.round(savings);
};

This displays:

Original file size
Compressed file size
Percentage saved

It is a small touch, but seeing "Space Saved: 67%" feels surprisingly good.

Loading FFmpeg on Demand

FFmpeg.wasm is not small. We load it lazily so the page stays snappy:

// utils/ffmpegLoader.ts
import { fetchFile, toBlobURL } from "@ffmpeg/util";

let ffmpeg: any = null;
let fetchFileFn: any = null;

export async function loadFFmpeg() {
  if (ffmpeg) return { ffmpeg, fetchFile: fetchFileFn };

  const { FFmpeg } = await import("@ffmpeg/ffmpeg");

  ffmpeg = new FFmpeg();
  fetchFileFn = fetchFile;

  const baseURL = "https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.6/dist/umd";

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
  }, {
    corePath: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  });

  return { ffmpeg, fetchFile };
}

Dynamic import keeps the module out of the initial bundle. Blob URLs sidestep CORS issues. And caching the instance means subsequent compressions do not pay the startup cost again.

Memory Management

Object URLs and virtual filesystem entries both leak if you forget them. We clean up on reset:

const reset = useCallback(() => {
  if (selectedFile) {
    URL.revokeObjectURL(selectedFile.previewUrl);
    if (selectedFile.compressedUrl) URL.revokeObjectURL(selectedFile.compressedUrl);
  }
  setSelectedFile(null);
  setError(null);
  setCompressionPreset("medium");
  setTargetResolution("original");
  setCustomBitrate("");
  setUseCustomSettings(false);
}, [selectedFile]);

And after each compression:

await ffmpeg.deleteFile(inputName);
await ffmpeg.deleteFile(outputName);

Without this, repeated use would eventually hit the browser's memory ceiling.

What We Learned

A few things caught us off guard while building this:

CRF is not a bitrate: Users often expect CRF 23 to produce the same file size every time. It does not — it targets a quality level, so a static screen recording at CRF 28 might be 5MB while a chaotic action scene at the same CRF could be 50MB. That is why we pair CRF with -maxrate as a safety cap.
-movflags +faststart is essential: Without it, the generated MP4 has to fully download before playback starts. With it, playback begins almost instantly. For a tool that generates videos people will likely watch in their browser, this matters a lot.
MKV support is surprisingly useful: A lot of screen recorders and gaming clips output MKV by default. Supporting it means users do not have to convert first.
Custom bitrate is a power-user trap: Give people a text box and someone will type 999999M. We do not aggressively validate (FFmpeg will just error out), but we probably should add a sanity check eventually.

Try It Out

Got a video that is too fat for Discord, email, or your phone's storage? You can shrink it right now. No account, no upload, no mysterious quality settings.

👉 Video Compressor

Drag your video in, pick a preset or dial in your own settings, and download the compressed version. Everything happens on your machine — your video never leaves your browser.

Burn Subtitles Into Videos Without Uploading a Single Byte

monkeymore studio — Fri, 24 Apr 2026 03:29:36 +0000

Adding subtitles to a video shouldn't require handing your file over to some cloud service. Whether it's a personal vlog, a client interview, or a clip you don't want floating around the internet, uploading feels like overkill for something this simple.

We thought the same thing. So we built a subtitle editor that runs entirely in your browser. You pick your video, type your subtitles, tweak the look, and hit go. The output video gets rendered locally — your footage never touches a server.

Here's how we pulled it off.

Why Keep Subtitle Editing in the Browser?

Server-side subtitle tools are everywhere, but they all share the same annoying traits:

You have to upload first: A 2-minute 1080p video can easily be 200MB. That's a lot of waiting on a mediocre connection.
Privacy is murky: Once your file is on someone else's server, who knows where it ends up?
They nickel-and-dime you: Free tier gives you 3 videos a month, then suddenly it's $15.
No control over styling: Pick one of three presets and hope for the best.

Doing it in the browser fixes all of that:

Zero uploads: Everything stays on your machine
Instant processing: No queue, no "please wait while we process your file" emails
Full styling control: Font size, color, position — you decide
Actually free: You're using your own CPU, so we don't need to charge you

The catch? You're limited by your device's memory. But for short to medium-length clips, modern hardware handles it just fine.

How the Whole Thing Flows

From the moment you drop a video to the moment you download the subtitled version, here's what happens:

Let's walk through the interesting parts.

The Data Model

We keep the state intentionally flat. A video is represented by one VideoFile object, and subtitles are just an array of entries:

interface VideoFile {
  id: string;
  file: File;
  previewUrl: string;
  outputUrl?: string;
  outputFileName?: string;
  error?: string;
  processing?: boolean;
  progress?: number;
  videoWidth?: number;
  videoHeight?: number;
  duration?: number;
}

interface SubtitleEntry {
  id: string;
  startTime: number;
  endTime: number;
  text: string;
}

The duration field on VideoFile is useful because it lets us validate subtitle timings — you can't have a subtitle that starts after the video ends. previewUrl is a standard URL.createObjectURL() pointing to the raw file, so the browser's native <video> element can play it immediately.

Loading FFmpeg on Demand

FFmpeg.wasm is heavy. We're talking several megabytes of JavaScript and WebAssembly. We definitely don't want to make users download that just to look at our landing page.

Our loader fetches it lazily and caches the instance:

// utils/ffmpegLoader.ts
import { fetchFile, toBlobURL } from "@ffmpeg/util";

let ffmpeg: any = null;
let fetchFileFn: any = null;

export async function loadFFmpeg() {
  if (ffmpeg) return { ffmpeg, fetchFile: fetchFileFn };

  const { FFmpeg } = await import("@ffmpeg/ffmpeg");

  ffmpeg = new FFmpeg();
  fetchFileFn = fetchFile;

  const baseURL = "https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.6/dist/umd";

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
  }, {
    corePath: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  });

  return { ffmpeg, fetchFile };
}

The dynamic import (await import("@ffmpeg/ffmpeg")) keeps the module out of the initial bundle. toBlobURL fetches the core files from jsdelivr and turns them into blob URLs, sidestepping CORS issues. And because we cache the ffmpeg instance at the module level, subsequent conversions don't need to pay the startup cost again.

From User Input to SRT

The heart of any subtitle tool is the SRT format. It's dead simple, which is why it's still the universal standard after 20+ years:

1
00:00:00,000 --> 00:00:03,500
Hello, this is the first subtitle

2
00:00:03,500 --> 00:00:07,200
And here's the second one

Each entry has an index, a time range in HH:MM:SS,mmm format, the text itself, and a blank line separator.

Our formatTime function converts raw seconds into that format:

const formatTime = (seconds: number): string => {
  const hrs = Math.floor(seconds / 3600);
  const mins = Math.floor((seconds % 3600) / 60);
  const secs = Math.floor(seconds % 60);
  const ms = Math.floor((seconds % 1) * 1000);
  return `${hrs.toString().padStart(2, "0")}:${mins.toString().padStart(2, "0")}:${secs.toString().padStart(2, "0")},${ms.toString().padStart(3, "0")}`;
};

And generateSRT stitches the entries together:

const generateSRT = (): string => {
  return subtitles.map((sub, index) => {
    return `${index + 1}\n${formatTime(sub.startTime)} --> ${formatTime(sub.endTime)}\n${sub.text}\n`;
  }).join("\n");
};

One subtle UX decision: when you add a new subtitle, it automatically starts at the end of the previous one. No one wants to manually type 00:00:15.000 for the fifth time.

const addSubtitle = () => {
  const lastSub = subtitles[subtitles.length - 1];
  const newStart = lastSub ? lastSub.endTime : 0;
  setSubtitles([...subtitles, {
    id: Date.now().toString(),
    startTime: newStart,
    endTime: newStart + 3,
    text: ""
  }]);
};

Burning the Subtitles with FFmpeg

This is where the magic happens. FFmpeg has a subtitles video filter that can read an SRT file and burn the text directly into the video frames. Combined with force_style, we get full control over how it looks.

const processVideo = async () => {
  if (!selectedFile || !ffmpegRef.current) return;

  const validSubtitles = subtitles.filter(s => s.text.trim() !== "");
  if (validSubtitles.length === 0) {
    setError("Please add at least one subtitle with text");
    return;
  }

  setIsProcessing(true);
  setSelectedFile(prev => prev ? { ...prev, processing: true, progress: 0 } : null);

  try {
    const ffmpeg = ffmpegRef.current;
    const inputName = "input.mp4";
    const srtName = "subtitles.srt";
    const outputName = "output.mp4";

    const fileArrayBuffer = await selectedFile.file.arrayBuffer();
    await ffmpeg.writeFile(inputName, new Uint8Array(fileArrayBuffer));

    const srtContent = generateSRT();
    await ffmpeg.writeFile(srtName, new TextEncoder().encode(srtContent));

    await ffmpeg.exec([
      "-i", inputName,
      "-vf", `subtitles=${srtName}:force_style='FontSize=${settings.fontSize},PrimaryColour=&H00FFFFFF,OutlineColour=&H00000000,Outline=1,Shadow=0,MarginV=20,Alignment=${settings.position === "top" ? "6" : "2"}'`,
      "-c:a", "copy",
      "-y",
      outputName
    ]);

    const data = await ffmpeg.readFile(outputName);
    const uint8Data = data instanceof Uint8Array ? data : new Uint8Array();
    const buffer = new ArrayBuffer(uint8Data.length);
    new Uint8Array(buffer).set(uint8Data);
    const blob = new Blob([buffer], { type: "video/mp4" });
    const outputUrl = URL.createObjectURL(blob);
    const baseName = selectedFile.file.name.replace(/\.[^/.]+$/, "");

    setSelectedFile(prev => prev ? {
      ...prev,
      outputUrl,
      outputFileName: `${baseName}_with_subtitles.mp4`,
      processing: false,
      progress: 100,
    } : null);

    await ffmpeg.deleteFile(inputName);
    await ffmpeg.deleteFile(srtName);
    await ffmpeg.deleteFile(outputName);
  } catch (err) {
    setError("Failed to add subtitles to video");
    setSelectedFile(prev => prev ? { ...prev, error: "Processing failed", processing: false } : null);
  } finally {
    setIsProcessing(false);
  }
};

Breaking down that FFmpeg command:

-i input.mp4 — the source video
-vf subtitles=subtitles.srt:force_style=... — the subtitle filter with custom styling
-c:a copy — copy the audio stream as-is, no re-encoding
-y — overwrite output if it exists

The force_style parameters deserve a closer look:

Parameter	What it does
`FontSize`	Self-explanatory — text size in pixels
`PrimaryColour`	Text color in BGR hex (`&H00FFFFFF` = white)
`OutlineColour`	Outline color (`&H00000000` = black)
`Outline`	Outline thickness — 1 gives a nice crisp edge
`Shadow`	Drop shadow depth — we keep it at 0 for cleanliness
`MarginV`	Vertical margin from the edge
`Alignment`	`2` = bottom center, `6` = top center

Using -c:a copy is a deliberate optimization. Re-encoding audio is slow and unnecessary for subtitle burning. By copying the audio stream, we save CPU cycles and preserve the original audio quality.

The Styling Controls

Users get three knobs to turn:

Font size (12px to 48px): A slider that lets you balance readability with not-blocking-half-the-video.

Color (white or yellow): White is the safe default. Yellow stands out better on bright scenes.

Position (top or bottom): Bottom is standard for subtitles. Top is useful if you need to avoid existing on-screen text or lower-third graphics.

We also track bgOpacity in the settings state, though the current implementation leans on FFmpeg's built-in outline for readability rather than a background box:

const [settings, setSettings] = useState({
  fontSize: 24,
  fontColor: "white",
  position: "bottom",
  bgOpacity: 0.5,
});

The bgOpacity is there as a foundation — if we ever want to add a semi-transparent background behind the text, the state is ready.

Progress Tracking

Nobody likes staring at a frozen spinner. FFmpeg.wasm emits progress events during processing:

ffmpeg.on("progress", ({ progress }: { progress: number }) => {
  setSelectedFile(prev => prev ? { ...prev, progress: Math.round(progress * 100) } : null);
});

This feeds a progress bar that actually moves, which goes a surprisingly long way toward making the wait feel acceptable.

Cleanup Is Not Optional

Object URLs and virtual filesystem entries both leak memory if you forget about them. We clean up on two occasions:

After processing:

await ffmpeg.deleteFile(inputName);
await ffmpeg.deleteFile(srtName);
await ffmpeg.deleteFile(outputName);

When the user starts over:

const reset = useCallback(() => {
  if (selectedFile) {
    URL.revokeObjectURL(selectedFile.previewUrl);
    if (selectedFile.outputUrl) URL.revokeObjectURL(selectedFile.outputUrl);
  }
  setSelectedFile(null);
  setError(null);
  setSubtitles([{ id: "1", startTime: 0, endTime: 3, text: "" }]);
}, [selectedFile]);

Without this, repeated use of the tool would eventually exhaust the browser's memory limit.

What We Learned Building This

A few things surprised us along the way:

SRT is surprisingly forgiving: As long as the index and timecode format are correct, FFmpeg doesn't care if there are extra blank lines or weird indentation.
The subtitles filter is picky about paths: It expects the SRT filename relative to the working directory. Since we're using FFmpeg's virtual filesystem, the filename alone is enough.
-c:a copy saves way more time than you'd think: On a 2-minute test clip, re-encoding audio added 40% to the total processing time. Copying it made the tool feel snappy.
Users immediately want to adjust timing after seeing the preview: We originally had a single "process" button with no preview. Adding the video player before processing turned out to be essential — people need to see where their subtitles land.

Try It Out

If you've got a video that needs subtitles, you can burn them in right now. No upload, no account, no waiting in a queue.

👉 Add Subtitles to Video

Drag your video in, type your subtitles, pick your style, and download the result. Everything happens on your machine — your video is yours from start to finish.