DEV Community: Hammad Shams Uddin

You cannot round three numbers that have to add up to a fourth

Hammad Shams Uddin — Mon, 24 Aug 2026 19:36:19 +0000

A macro calculator takes a calorie target and splits it into grams of carbs, protein and fat. Mine did this:

const carb = cals * split[0] / 100 / 4;
const prot = cals * split[1] / 100 / 4;
const fat  = cals * split[2] / 100 / 9;

return `${Math.round(prot)} / ${Math.round(carb)} / ${Math.round(fat)} g`;

Ask it for 2,000 kcal on a 40/30/30 split and it says 150 / 200 / 67 g.

Multiply that back out — protein and carbs are 4 kcal a gram, fat is 9:

200 × 4  +  150 × 4  +  67 × 9  =  2,003

You asked for 2,000. It is not a big miss. It is a miss on the one thing the tool exists to do, and any user with a phone can find it, because adding up to the number you typed is the entire point of a split.

It was not one unlucky input either:

target	plan	it said	that is actually
2,000	balanced	150 / 200 / 67	2,003
2,000	keto	125 / 25 / 156	2,004
1,750	low carb	175 / 109 / 68	1,748
2,500	high protein	250 / 250 / 56	2,504

Every plan. Every time.

Why rounding each one cannot work

Because the three values are not independent. They have to satisfy

4c + 4p + 9f = calories

and Math.round does not know that. It rounds c to whatever is nearest to c, which is the right answer to a question nobody asked. The constraint is on the sum, and three separately-correct roundings do not add up to a correctly-rounded total.

This is the same family as a percentage table where the column has to total 100% and comes out at 99.9%. The usual fix there is largest-remainder: hand out the floors, then give the spare units to whoever was robbed most by rounding down.

That does not work here, and the reason is the interesting part.

The weights are 4, 4 and 9

In a percentage table every unit is worth the same, so you can move one from anywhere to anywhere. Here, moving a gram of carbs changes the total by 4, and moving a gram of fat changes it by 9. You cannot always close a gap of 3 kcal, because nothing in your inventory is worth 3.

So the order matters. Pick fat first, and pick it so that what is left over divides by 4 — because whatever is left has to be made up entirely of carbs and protein, and those only come in fours.

const want = kcal * split[2] / 100 / 9;      // ideal fat, in grams

for (let f = Math.round(want) - 3; f <= Math.round(want) + 3; f++) {
  const left = kcal - 9 * f;
  if (left < 0 || left % 4 !== 0) continue;  // no integer c,p can finish this
  const rest = left / 4;                     // carbs + protein, in grams
  const c = Math.round(rest * split[0] / (split[0] + split[1]));
  const p = rest - c;
  // ...
}

And the search never has to go far. 9 ≡ 1 (mod 4), so incrementing f by one shifts kcal - 9f by one modulo 4 — which means one fat value in every four consecutive integers satisfies the condition. A candidate always exists within two grams of the ideal. There is no failure case to handle, only a choice to make.

The first version was still wrong, and quietly

I originally took the nearest valid f and stopped. Every combination hit its calorie target exactly, the tests I had written passed, and I nearly shipped it.

Then I measured how far the grams had drifted from the ideal split, which is the other thing the tool is promising:

worst drift: 4.75 g on protein at 2,500 kcal keto

Keto puts 70% of the calories in fat, so fat is large, its rounding error is large in kcal, and all of that leftover lands on carbs and protein. Taking the first valid fat value meant taking whatever drift came with it.

There are usually several valid candidates in that ±3 window, and they do not cost the same. Scoring all of them by total drift and keeping the best brings the worst case down to 3.94 g — under 3% of that macro — while still landing exactly on the calorie target. Seven candidates is nothing to evaluate.

That is the general lesson and it is not about food:

Satisfying the constraint is necessary, not sufficient. The first solution that satisfies it is rarely the best one, and if you only assert on the constraint your tests will happily bless the worst member of the solution set.

Testing it

Sweeping, not sampling:

for (let cals = 800; cals <= 4000; cals += 25) {
  for (const p of Object.values(PLANS)) {
    const g = macroGrams(cals, p);
    if (g.kcal !== cals) miss++;
  }
}

516 combinations, and they all have to land exactly. Sampling round numbers would have been useless here — whether the bug shows depends on where the ideal fat value happens to fall relative to a multiple of four, and 2,000 kcal is exactly the kind of tidy input that could have gone either way.

The drift bound in the test is the measured number, not a guess:

// 3.94 g is what the algorithm actually holds across the swept range,
// on protein in a keto split. Four is that, rounded up.
check('no macro drifts more than 4 g from its ideal', worst <= 4, true);

Writing worst <= 10 because it passes is not a test, it is a formality. Writing worst <= 3 because it sounds tidy fails on an input that is perfectly fine. Measure the bound, then assert it.

And say the number

The last change was not code:

Protein            149 g
Carbohydrates      198 g
Fat                 68 g
These add up to  2,000 kcal

The reader was going to multiply it out anyway. Better that the page does it first.

I build Utilorax, a set of free browser-based tools. This came out of the macro calculator, which now hands you three numbers that add up to the one you asked for.

A missing exchange rate is not an exchange rate of 1

Hammad Shams Uddin — Thu, 20 Aug 2026 12:56:18 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

var fx = (rates.rates && rates.rates[v.currency]) || 1;

That line converts a crypto price into whatever currency the visitor picked. It has been on my site for months. It is one line, it reads like defensive programming, and it is capable of being wrong by a factor of 280.

What `|| 1` means here

The rate table comes from a currency API. When that API fails, my server-side cache falls back to the only rate it can be sure of:

return $c['data'] ?? ['USD' => 1.0];

Which is honest. USD => 1.0 is true, and the fallback contains nothing it cannot vouch for.

Then the browser asks that table for PKR, gets undefined, and || 1 turns "I don't have that" into "the rate is 1".

So the page renders:

1 BTC = 95,000.00 PKR

The real figure is about 26,600,000. And there is no asterisk, no greyed-out state, no "approximate" — it looks exactly like the correct answer, because it is produced by exactly the same code path as the correct answer.

The second one, in the same function

Three lines down:

var ago = rates.cached_age_sec != null ? Math.round(rates.cached_age_sec / 60) : 0;
...
note: 'Live spot price, updated about ' + (ago <= 0 ? 'just now' : ago + ' min ago')

cached_age_sec is null when the cache layer cannot say how old the figure is. The ternary is careful — it checks for null — and then maps that null onto 0. One line later, 0 is read as "updated just now".

The one case where the freshness is genuinely unknown is the case that produces the most reassuring sentence on the page.

The shape

Both are the same mistake wearing different clothes:

A value that was absent, replaced by a plausible default, and then rendered with the same confidence as a measured one.

The defaults are not stupid. A rate of 1 is the identity. An age of 0 is the neutral element. In isolation each choice looks like the sensible thing to reach for when something is missing. The damage is done at the point of display, where the substitute and the real thing become indistinguishable.

And it is worse than crashing. A crash is a bad experience that tells the truth. This tells a confident lie in the visitor's own currency.

The part that makes it embarrassing

The correct handling was already in the file. Twenty lines above, the plain currency converter has always done this:

var fr = rates.rates[v.from], to = rates.rates[v.to];
if (!(fr > 0) || !(to > 0)) {
  return { error: 'That currency is not in the live feed.' };
}

Same file. Same rate table. Same author. One engine refuses; the two next to it substitute. Nothing distinguishes them except which one I happened to write while thinking about failure.

That is the real lesson and it is not about currencies: defensive habits do not generalise on their own. Getting it right once in a file is not evidence the file is right. It is one data point about one function.

The fixes

Refuse, and name what is missing:

var fx = (rates.rates && rates.rates[v.currency] > 0) ? rates.rates[v.currency] : null;
if (fx === null) {
  return { error: 'Live rates for ' + (v.currency || 'that currency')
    + ' are unavailable right now — try USD, or refresh in a moment.' };
}

Note > 0 rather than a truthiness check. A rate of 0 is as unusable as a missing one, and undefined > 0 is false, so the two collapse into the same branch without a separate test.

And let unknown stay unknown:

function freshness(age, unit) {
  if (age === null || age === undefined) { return 'age unknown'; }
  if (age <= 0) { return 'updated just now'; }
  return 'updated about ' + age + ' ' + unit + ' ago';
}

Three sentences for three states, instead of two sentences for three states. The bug was entirely in that missing third branch.

Testing a feed that has failed

Neither bug is reachable by using the page. The upstream API has to be partially down — up enough to return a table, broken enough that your currency is not in it. I have never once seen that state in a browser, and I never will on purpose.

So the engines had to become reachable from a test. They live in a browser IIFE, so they got the same export guard the widgets file already used:

if (typeof module !== 'undefined' && module.exports) {
  module.exports = { ENGINES, freshness, trueCost };
}

Then the fixture is the whole point — a feed that is deliberately, plausibly incomplete:

const feed = {
  coins: { bitcoin: 95000 },        // but not dogecoin
  rates: { USD: 1, EUR: 0.92 },     // but not PKR
  cached_age_sec: 120,
};

That is not a made-up shape. It is precisely what the server returns when the currency provider is down and the crypto provider is not: ['USD' => 1.0] and nothing else.

One of the nineteen assertions is about a function I did not change:

const bad = ENGINES.currencyConvert({ amount: '100', from: 'USD', to: 'PKR' }, fx);
check('and a missing one was always refused', typeof bad.error === 'string', true);

It cannot fail today. It is there so the three engines that read the same table cannot quietly drift apart again — which is how they got out of step in the first place.

I build Utilorax, a set of free browser-based tools. This came out of the crypto price converter and the gold & silver price calculator, both of which now tell you when they don't know rather than guessing on your behalf.

Your amortisation schedule is one row short, and only sometimes

Hammad Shams Uddin — Thu, 20 Aug 2026 09:20:13 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

You cannot be billed $1,896.2027.

That is the whole bug, and I had it in a loan calculator and an amortisation schedule for months without noticing, because on most of the numbers I tested with it makes no difference at all.

The line

Standard amortisation. Work out the monthly payment, then walk the balance down month by month:

let pay = principal * r / (1 - Math.pow(1 + r, -n));

let balance = principal;
while (balance > 0.005) {
  const interest      = balance * r;
  let   principalPart = pay - interest;
  if (principalPart > balance) principalPart = balance;   // final payment
  balance -= principalPart;
  rows.push({ payment: principalPart + interest, interest, balance });
}

That is correct arithmetic and it is not what happens to you.

pay comes out of that formula as something like 1896.2027149.... The schedule then charges 1896.2027149... every month for thirty years. Your lender charges you $1,896.20, because money has two decimal places, and the two-hundredths of a cent they are not collecting has to come from somewhere.

What it costs

$300,000 at 6.5% over 30 years, run both ways:

	payments	last payment
unrounded `1896.2027…`	360	$1,896.20
rounded `1896.20`	361	$4.53

The schedule said the loan ends in month 360. In reality there is a 361st bill for $4.53, because paying two-hundredths of a cent less each month leaves $4.53 of principal standing when the schedule thinks you are done.

Four dollars is not the point. The number of rows is wrong, and that is the one thing an amortisation schedule exists to tell you.

Why it survived

Here is the same comparison on a different loan:

	payments	last payment
unrounded	360	$1,380.51
rounded	360	$1,379.86

$250,000 at 5.25%, and both methods land on 360. The rounding happens to fall the other way and the stub is absorbed by the final payment.

So the bug is real, reproducible, and invisible on plenty of ordinary inputs. Any test suite built from round numbers — $250,000, 5%, 30 years — passes with it in. Mine would have.

This is a shape worth recognising, because it is not really about money:

A test case that agrees with both the correct and the incorrect implementation is not evidence of anything. It feels like coverage. It is the absence of coverage, dressed up.

When I wrote the tests afterwards I deliberately kept the $250,000 case in, alongside the $300,000 one. Not because it catches the bug — it cannot — but because a fix that only works on the input that exposed the problem is not a fix, and I want to know if I ever break the agreeing case too.

The fix is one line and one consequence

let pay = principal * r / (1 - Math.pow(1 + r, -n));
pay = Math.round(pay * 100) / 100;      // a lender bills to the cent

The consequence is that the loop has to be allowed to run past n. If you wrote for (let m = 0; m < n; m++) you now silently drop the stub payment and end with a non-zero balance, which is worse than where you started — the schedule is still 360 rows but now it does not add up. The while (balance > 0.005) form handles it, with a guard so a pathological rate cannot spin forever.

The same mistake, upstairs

The summary calculator had its own version:

const emi   = principal * r * Math.pow(1+r, n) / (Math.pow(1+r, n) - 1);
const total = emi * n;                    // <- both wrong things at once

total multiplies the unrounded payment, while the page prints the rounded one. So "Monthly payment $1,896.20" and "Total of payments $682,633.47" are not consistent with each other: a visitor with a phone can multiply 1896.20 by 360, get $682,632.00, and be right that something is off.

And it assumes the term is exactly n payments, which is the bug above wearing a different hat.

Running the real schedule fixes both, and 360 iterations of arithmetic costs nothing:

function trueCost(principal, monthlyRate, months) {
  let pay = principal * monthlyRate / (1 - Math.pow(1 + monthlyRate, -months));
  pay = Math.round(pay * 100) / 100;

  let balance = principal, paid = 0, interest = 0, count = 0;
  while (balance > 0.005 && count < months + 600) {
    count++;
    const i = balance * monthlyRate;
    let principalPart = pay - i;
    if (principalPart > balance) principalPart = balance;
    balance -= principalPart;
    if (balance < 0.005) balance = 0;
    interest += i;
    paid += principalPart + i;
  }
  return { payment: pay, months: count, total: paid, interest };
}

It also gives you the number of payments for free, which is worth showing — it is the answer to "when am I actually finished", and it is not always the number you typed in.

Tests a borrower could run

The assertions that turned out to be worth the most are the ones checkable against a real statement, not against another implementation of the same formula:

every dollar of principal is repaid — no more, no less
interest plus principal equals what was paid
the final balance is exactly zero, not 1e-9
the payment is a whole number of cents
an extra $200 a month shortens the term and costs less interest

None of those restate the amortisation formula, which is the point. A test that recomputes principal * r / (1 - (1+r)^-n) and compares it to the code passes whether or not the code is right about anything else.

I build Utilorax, a set of free browser-based tools. This came out of the loan calculator, the mortgage calculator and the amortisation schedule, all three of which now count the 361st payment.

I made twenty tools take twenty files. Every bug was state that outlived one file.

Hammad Shams Uddin — Wed, 19 Aug 2026 16:56:10 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

My browser-based tools each took exactly one file. Converting twenty tracks meant twenty page loads, and on the background remover each of those re-downloaded a 44 MB segmentation model to do three seconds of work.

So I put a loop around the work. That is genuinely most of it — read the settings once, run them over each file, collect the results, zip them.

Then I tested it in a real browser and found three bugs. They look unrelated. They are the same bug: something that was fine as a single value became wrong the moment there were two files, and none of them announced itself.

Bug one: the second file overwrote the first

The single-file version wrote into a fixed name on ffmpeg.wasm's virtual filesystem:

function runSingle(o) {
  const inN  = 'in.'  + ext(files[0].name);
  const outN = 'out.' + pick.ext;
  // ...
}

That filesystem is shared for the whole session, not per call. Loop it, and clip two writes in.mp4 over clip one — which, if you are unlucky with timing, is not even a crash. It is a correct-looking output that contains the wrong video.

The fix is boring: the index goes in the name.

function runSingle(o, file, idx) {
  const inN  = 'in'  + idx + '.' + ext(file.name);
  const outN = 'out' + idx + '.' + pick.ext;

What is not boring is the second half. A file that fails leaves its input behind, and the next twelve files then run in a workspace that is filling up with dead inputs. So the cleanup has to happen on the failure path too, not just the success one:

  }).then(function (data) {
    drop(inN); drop(outN);
    return data;
  }, function (e) {
    drop(inN); drop(outN);   // <- the one people forget
    throw e;
  });

Bug two: the array that was empty for the whole run

This is the one worth the article.

Two output files can want the same name. song.wav and song.flac both convert to song.mp3, and a zip quietly keeps only the last of a repeated name — so one of the two conversions silently vanishes. I wrote a dedupe for it:

const out = {
  name: uniqueName(stem + '.png', outputs),   // compare against what we have so far
  blob: blob
};

And a preview, so a batch shows a picture rather than only a list of names:

if (!outputs.length) { showPreview(blob); }   // only the first one

Both read outputs. And outputs is assigned like this:

series(files, job).then(function (res) {
  outputs = res.done;      // <- after every file has finished
  render(outputs);
});

So for the entire duration of the run — the only time those two lines execute — outputs is [].

The consequences are not symmetrical, which is why this took a test to catch:

!outputs.length was always true, so every file overwrote the preview. The batch appeared to work and showed the last image. Nothing looked broken; the preview was just the wrong file, and only if you knew which one you dropped first would you notice.
uniqueName(want, []) never found a clash, so cat.png and cat.jpg both produced cat-no-bg.png and the zip contained one of them. The results list on screen showed the name twice, which is the only reason I looked.

The fix is one line and it is not the dedupe:

const made = [];                       // accumulate where the work happens
series(files, function (f, i) {
  return job(f, i).then(function (out) {
    const o = { name: uniqueName(stem, made), blob: out };
    if (!made.length) { showPreview(out); }
    made.push(o);
    return o;
  });
}).then(function (res) { outputs = res.done; });

The general shape:

A variable assigned from a promise's result is empty for exactly as long as the work that produces it is running. If anything inside that work reads it, it reads the empty version, every time.

It is easy to miss because the code reads correctly in the order it is written. outputs = res.done sits above render(outputs) and below the loop, so it looks like it happens between them. It happens after both.

Bug three: an operation completing is not evidence it did anything

I have written about this one before, and batching brings it back sharper. ffmpeg.run() resolves whether ffmpeg succeeded or not. With one file, a silent failure means the visitor sees an error a moment later and tries again. With twenty, one silent failure means nineteen good files and one wrong one, in a zip, unremarked.

So each iteration has to judge the output, not the promise:

const data = ffmpeg.FS('readFile', outN);
if (!data || !data.length) {
  throw new Error('ffmpeg wrote no output for ' + file.name);
}

And the failure has to be per-file rather than fatal. One unreadable file out of twenty must not cost someone the other nineteen — it should be named on the results page, next to the files that worked:

alpha.mp3          7 KB   Save
song.mp3           6 KB   Save
song (2).mp3       5 KB   Save
1 file could not be processed and is not included. broken.wav

Sequential, not Promise.all

Worth saying because it looks like the obvious optimisation. There is one ffmpeg instance behind one core and one ONNX session. Running the files concurrently does not make them finish sooner; it interleaves them, multiplies peak memory by the number of files, and turns a readable progress bar into a lie.

The batch is a reduce over promises, and the bar gives each file an equal slice:

function setProgress(r) {
  const p = Math.round(((done + clamp01(r)) / total) * 100);
  bar.style.width = p + '%';
}

How I actually found these

None of the three would have been caught by reading the diff, and two of them produce a page that looks like it worked.

They came out of driving the shipped page in a real browser: build the fixtures in JavaScript, hand them to the widget as a synthetic DataTransfer, click the button, and read the DOM afterwards. The fixtures are the part that matters — four files where two deliberately fight over one output name and one is eight bytes of garbage:

dt.items.add(file('alpha.wav', wav(0.5, 440)));
dt.items.add(file('song.wav',  wav(0.4, 300)));
dt.items.add(file('song.m4a',  wav(0.3, 600)));   // same stem -> collision
dt.items.add(file('broken.wav', new Uint8Array([1,2,3,4,5,6,7,8]).buffer));

A happy-path batch of three well-named valid files passes with all three bugs present. That is not a test; it is a screenshot with extra steps.

I build Utilorax, a set of free browser-based tools. The batch now runs on the audio converter, the video converter and the background remover — nothing is uploaded, so the loop and the failures are all on your own machine.

The file existed, so I assumed the check passed

Hammad Shams Uddin — Fri, 14 Aug 2026 22:44:18 +0000

A user sent me two clips and a screenshot. My video merge tool had run to 100%, said "Applying transitions…", and then thrown:

FS error: readFile 'merged.mp4'

The error is honest and useless. merged.mp4 does not exist. It does not say why, because by the time you ask, the thing that should have made it has already finished and moved on.

The cause turned out to be four functions upstream, and the shape of the mistake is one I keep meeting: a check that tests whether something exists when the question was whether it has a particular property.

What the tool does

Merging clips with different sizes and formats means normalising them first — same dimensions, same frame rate, same codecs — and only then joining. If the user asked for a transition, the join is an xfade for the picture and an acrossfade for the sound.

That second one matters more than it looks.

The check

Normalising ran this per clip:

ffmpeg.run('-i', inN, '-vf', vf,
           '-c:v', 'libx264', '-preset', 'veryfast', '-crf', '23',
           '-c:a', 'libmp3lame', '-b:a', '128k', outN)
  .then(() => {
    try {
      ffmpeg.FS('readFile', outN);
    } catch (e) {
      // no audio in this clip — redo it with a silent track
      return ffmpeg.run(/* ...anullsrc version... */);
    }
  });

Read the intent: if the encode failed because the source had no audio, redo it with generated silence, so every input to the transition has a sound track.

Read what it does: if the output file is missing, redo it.

Those are not the same sentence, and the gap between them is the bug.

Give ffmpeg a video-only file and ask it to encode audio with -c:a libmp3lame, and it does not fail. There is no audio stream, so it encodes the video, writes no audio stream, and exits successfully. The file exists. The catch never runs. The silence fallback — written specifically for this case — never fires.

Then the transition builds its filter graph:

[0:a][1:a]acrossfade=d=0.5[aout]

[0:a] does not exist. The graph fails, no output is written, and one .then() later you get an error about merged.mp4.

Why it survived

Two reasons, and the second is the interesting one.

Clips with sound worked perfectly. Every file I had tested with was a screen recording with audio or a phone video. The failing case is a clip with no audio track at all — which describes every AI-generated clip, most screen recordings, and any video someone has already stripped the sound from. It is not an edge case. It is a whole category of ordinary file I did not happen to own.

And ffmpeg.wasm does not reject on ffmpeg failure. ffmpeg.run() resolves whether the command succeeded or not. A filter graph that fails produces no output and no rejection, so the await returns normally and execution carries on into code that assumes the file is there. Every error in this class arrives late and blames the wrong line.

The fix is to ask the actual question

You cannot infer "has an audio stream" from "a file appeared". So ask:

function hasAudio(name) {
  const probe = 'probe_' + name + '.mka';
  return ffmpeg.run('-i', name, '-vn', '-map', '0:a:0', '-c', 'copy', '-t', '0.05', probe)
    .then(() => {
      let found = false;
      try { found = ffmpeg.FS('readFile', probe).length > 0; } catch (e) { found = false; }
      try { ffmpeg.FS('unlink', probe); } catch (e) {}
      return found;
    })
    .catch(() => false);
}

-map 0:a:0 names the first audio stream. If there is no audio stream, the mapping cannot be satisfied and nothing is written. It is a stream copy of 50 milliseconds, so it costs nothing beside the encode that follows, and the answer is about the thing I actually care about.

Then the command is chosen once, rather than attempted and repaired:

const args = audible
  ? ['-i', inN, '-vf', vf, /* ... */ '-c:a', 'libmp3lame', outN]
  : ['-i', inN, '-f', 'lavfi', '-i', 'anullsrc=channel_layout=stereo:sample_rate=44100',
     '-shortest', '-map', '0:v', '-map', '1:a', '-vf', vf, /* ... */ outN];

I did consider reading ffmpeg's log output for Stream #0:1: Audio: instead. It works, and I did not use it, because 0.11 and the 0.12 adapter surface logging differently and I would have had two code paths to keep true. A probe behaves identically on both.

Testing something that only runs in a browser

There is no ffmpeg binary on my machine or my server — the whole point is that this runs in the user's browser via WebAssembly. And headless Chrome's virtual time does not advance a web worker, so the usual scripted approach hangs at the first run().

What worked: a page that builds its own fixtures with lavfi, runs the real checks, and POSTs its results back to a PHP file so the run can outlive any screenshot timing.

made sil.mp4=28362B snd.mp4=48141B
ok   snd.mp4 -> hasAudio=true    (expected true)
ok   sil.mp4 -> hasAudio=false   (expected false)
ok   acrossfade on silent clips produces no output

That third line is the one worth writing. It is not a test of the fix — it is a test of the diagnosis. Before trusting the repair, prove the thing you blamed actually misbehaves the way you claim. I have shipped fixes for problems I had misdiagnosed, and they are worse than the original bug, because now the symptom is gone and the cause is still there.

The general version

The bug is not really about ffmpeg. It is this:

An operation completing is not evidence that it did what you wanted. It is evidence that it did not crash.

Some places the same shape shows up:

a file exists, so the write must have contained data
an HTTP request returned 200, so the response must be the resource you asked for
a command exited 0, so it must have produced output
a catch block did not run, so the happy path must have happened

Each of those is a check on the wrong noun. The fix is always the same and always feels like extra work: name the property you actually depend on, and ask about that — not about whatever is easiest to observe nearby.

And add the belt-and-braces, because you will get it wrong again somewhere. If the transition now fails for a reason I have not thought of, the tool joins the clips without one and says so, rather than handing anyone FS error: readFile 'merged.mp4'.

I build Utilorax, a set of free browser-based tools — this one came out of the video merger, which does now handle a silent clip.

Two scrolling panes is the wrong way to build a side-by-side diff

Hammad Shams Uddin — Wed, 12 Aug 2026 20:02:50 +0000

I had a text-compare tool that asked people to compare two things it would not show them at the same time.

One textarea, then another textarea underneath it, then a single-column unified diff below that — removals in red, additions in green, in the order a diff algorithm emits them. Everything on the page was correct and the tool was close to useless, because comparing is a thing your eyes do in parallel and the layout made it serial.

Rebuilding it as two columns turned out to have three problems in it. Only one of them is layout, and the interesting one is the layout problem.

Start with the diff you already have

A line-level diff comes out of a longest-common-subsequence backtrack as a flat list:

[
  { t: 'same', line: 'The quick brown fox' },
  { t: 'del',  line: 'jumps over the lazy dog' },
  { t: 'add',  line: 'leaps over the lazy dog' },
  { t: 'same', line: 'and runs away.' }
]

That is exactly what a unified view wants. It is not what a side-by-side view wants, and the difference is the whole job.

Problem one: an edited line is two entries

In that list, editing a line produces a del and an add — and in a longer diff they can be several rows apart, because the algorithm emits a run of removals and then a run of additions.

Render that naively into two columns and you get the removal on row 4 of the left column and the addition on row 9 of the right one. The view is now worse than the unified one: two columns, and the thing you are comparing is in different places in each.

So the walk has to buffer. Consecutive non-same entries are collected as a block, then paired off index by index:

function sideBySide(diff) {
  const rows = [];
  let i = 0, na = 0, nb = 0;         // line numbers, counted per side

  while (i < diff.length) {
    if (diff[i].t === 'same') {
      na++; nb++;
      rows.push({ kind: 'same', na, nb, a: diff[i].line, b: diff[i].line });
      i++;
      continue;
    }

    const dels = [], adds = [];
    while (i < diff.length && diff[i].t !== 'same') {
      (diff[i].t === 'del' ? dels : adds).push(diff[i].line);
      i++;
    }

    for (let k = 0; k < Math.max(dels.length, adds.length); k++) {
      const da = k < dels.length ? dels[k] : null;
      const db = k < adds.length ? adds[k] : null;
      if (da !== null) na++;
      if (db !== null) nb++;
      if (da !== null && db !== null) rows.push({ kind: 'chg', na, nb, a: da, b: db });
      else if (da !== null)           rows.push({ kind: 'del', na, nb: null, a: da, b: null });
      else                            rows.push({ kind: 'add', na: null, nb, a: null, b: db });
    }
  }
  return rows;
}

Two things worth noticing.

The blocks are rarely the same length. Three lines removed and one added means one paired row and two rows with an empty right side. That is correct — the surplus really has no counterpart — and it is why the pairing is a max() loop rather than a zip.

And the line numbers count separately per side, which is what every code review tool does and what people expect without being able to say so. After an insertion the two columns are permanently offset, and a number that pointed at "row 7 of the display" instead of "line 7 of that version" would be useless the moment you tried to find the line in your editor.

Problem two: the eye still has to re-read both lines

Once jumps over the lazy dog and leaps over the lazy dog sit next to each other, you still have to read both to find what moved. On a long line you read it three times.

The fix is the same algorithm one level down. Run the line diff over the two lines' word arrays and mark the tokens that differ:

function wordSegments(a, b) {
  const ta = a.split(/(\s+)/), tb = b.split(/(\s+)/);   // captured group keeps the spacing
  const left = [], right = [];
  lineDiff(ta, tb).forEach(x => {
    const blank = !x.line || !x.line.trim();
    if (x.t === 'same')      { left.push({ s: x.line }); right.push({ s: x.line }); }
    else if (x.t === 'del')  { left.push({ s: x.line, m: !blank }); }
    else                     { right.push({ s: x.line, m: !blank }); }
  });
  return [left, right];
}

Splitting on a captured separator (/(\s+)/ rather than /\s+/) is what makes this work. The whitespace comes back as its own token, so it survives the diff and the rebuilt line still reads like the original. Without it, marks land in the right places and every run of spaces collapses to one.

The blank check earns its place too. Whitespace tokens rarely match exactly — one line has two spaces where the other has three — so without it you get coloured blobs floating between words, drawing the eye to nothing.

One guard: lineDiff builds an (n+1) × (m+1) table, so two very long lines are quadratic in a way nobody wants on a keystroke. Past a threshold, mark the whole line and move on.

Problem three: two scrolling panes is a trap

This is the one I would have got wrong if I had started from the picture instead of the behaviour.

The obvious implementation of a side-by-side view is two panes, each scrolling its own content. It looks right in a mockup. It is a bad idea, and the reason is not performance or complexity — it is that the panes can drift.

Two independently scrollable panes have two scroll positions. Keeping them in step means listening to scroll on both, writing to the other, and guarding against the feedback loop that creates. Then you discover the panes have different content heights — one side has extra rows where the other has gaps — so equal scrollTop does not mean equal position, and you are mapping between them.

And the moment they are out of step by even one row, the view stops doing the one thing it exists to do. A diff that shows you line 40 on the left and line 41 on the right is not a diff; it is two lists.

The alternative is boring and cannot drift:

<div class="diff-row">
  <div class="diff-cell">…left…</div>
  <div class="diff-cell">…right…</div>
</div>

.diff-split-body { max-height: 32rem; overflow: auto; }   /* one scroller */
.diff-row  { display: grid; grid-template-columns: 1fr 1fr; gap: 1px; }
.diff-cell { display: flex; gap: .6rem; min-width: 0; }

One scroll container, one grid, two cells per row. The two halves of a row are in the same row element, so there is no state that could disagree. No scroll listeners, no synchronisation, no drift — because there is nothing to synchronise.

The general version of this: when two things must stay aligned, prefer a structure where misalignment is unrepresentable over code that keeps them aligned. Synchronising code has a bug rate. A shared row does not.

The bit that only shows up on a phone

Two columns of prose at 380px is unreadable, so under 720px both the inputs and the diff collapse to one column — old line above new, with a coloured left edge to say which is which.

The tempting shortcut is to keep the column headers and hide one. I did that first. On a stacked list the surviving header sits above rows from both versions and confidently mislabels half of them. Dropping the header entirely is more honest: the red and green edges already carry the information, and no text is better than text that is wrong for every second row.

Worth testing, and easy to

The pairing walk is pure data in, data out, which makes it worth pinning down properly. The cases that matter are not the happy path:

an edit lands on one row, old left and new right
a pure insertion has nothing on the left, and A's numbering does not advance
a pure deletion is the same in reverse
an uneven block (three removed, one added) pairs what it can and gives the surplus its own rows
identical input produces only same rows
an empty diff produces no rows

Plus, for the word marks: only the changed word gets marked, both lines rebuild to exactly the original text, whitespace is never marked, and the long-line guard does not lose any text.

Twenty-three assertions, no DOM, runs in a second. The line-numbering-after-an-insert case caught a real bug — worth more than the rest of the suite put together, and the one I would not have thought to check by hand.

I build Utilorax, a set of free browser-based tools — including the text compare this came out of.

Working out what a site is running — and where every check lies to you

Hammad Shams Uddin — Tue, 11 Aug 2026 17:09:51 +0000

You want to know what some site is built on. Maybe a competitor, maybe a client's old site nobody has the credentials for, maybe you just saw something fast and want to know why.

There are four places to look, and each one will confidently tell you something false under conditions you should know about. The checks are easy. Knowing when to disbelieve them is the actual skill.

1. DNS, and the CDN that hides everything behind it

The first instinct is to resolve the domain and see where it lands.

dig +short example.com

This is genuinely useful and it is also the check that misleads people most often, because an IP in front of a CDN is the CDN, not the host.

I ran this on my own site recently. The IP that came back belongs to Cloudflare. My actual server is on a shared host in a different country entirely, and nothing in DNS will tell you that — which is most of the point of putting Cloudflare there.

So the rule is: if the IP resolves to Cloudflare, Fastly, Akamai or a big cloud edge, you have learned who fronts the site and nothing about who hosts it. That is still worth knowing. Just do not write "hosted on Cloudflare" in your notes.

The records that survive the CDN are the ones it does not proxy. MX almost always points at the real mail provider. TXT is a gift — SPF records list every service allowed to send mail as that domain, which in practice is a list of the SaaS products the company pays for.

dig +short example.com MX
dig +short example.com TXT

My own domain demonstrates the whole point in two lines. The A record says Cloudflare (AS13335). The MX record says mx1.hostinger.com. The first tells you nothing about where the site lives; the second quietly names the host, because mail does not route through the CDN.

If you are not at a terminal, a browser DNS lookup will pull the same records, and there is a domain to IP tool for the plain A-record case.

2. Response headers, which are honest by accident

Headers are the highest-signal-per-second check there is, because they are mostly emitted by machines that have no interest in your investigation.

curl -sI https://example.com

What to read:

server — sometimes the real thing (nginx, Apache), often replaced by the CDN.
x-powered-by — when present, usually accurate and usually an oversight.
cf-cache-status — Cloudflare, and more interesting than it looks. HIT means the edge served it. DYNAMIC means Cloudflare was told not to cache this. BYPASS means something upstream explicitly said no.
via, x-vercel-id, x-amz-cf-id — the infrastructure signing its own work.

That cf-cache-status line is worth dwelling on, because it varies by path on the same site and the variation is the configuration, visible from outside. Two requests against my own domain:

/public/css/style.min.css   HIT       cache-control: public, max-age=31536000, immutable
/tools/dns-lookup           DYNAMIC   cache-control: private, max-age=0, must-revalidate

Assets cached at the edge for a year, HTML never cached at all. That is a deliberate setup and you can read it off in about four seconds without any access to the site.

The lie to watch for: headers describe the machine that answered, which on a CDN is an edge node in your own city, not the origin. A missing x-powered-by means the CDN stripped it, not that the site is not running PHP.

If you want status codes and the full redirect chain rather than raw headers, this status code checker follows the chain and shows each hop, which is the part that matters when you are chasing a redirect loop.

3. The HTML, which is where the CMS gives itself away

Frameworks leave litter. Fetch the page and look for it:

curl -s https://example.com | grep -oE '<meta name="generator"[^>]*>'
curl -s https://example.com | grep -oE '/wp-(content|includes)/[^"]*' | head

/wp-content/themes/something/ in an asset URL names the WordPress theme outright. <meta name="generator" content="WordPress 6.x"> does the same more politely. Shopify, Ghost, Wix and Squarespace all announce themselves similarly if nobody has bothered to turn it off.

There is a WordPress theme detector that does this pattern-matching for you and also reports the plugins it can see from asset paths, which is often the more interesting half.

The lie here is the biggest one on the list, and it is not the HTML's fault — it is yours. Plenty of pages build their content in JavaScript, so what curl returns is a shell and what a browser shows is the page. If you grep the raw HTML and find nothing, you have not learned that there is nothing there.

I lost an evening to exactly this last week. I was checking whether a publication's guest-author page linked to an application form, grepped the HTML for mailto: and forms, found neither, and concluded the route was elsewhere. The page renders its body client-side. Everything I wanted was there, in the browser, the whole time.

When the raw HTML looks empty, that is the signal to open devtools and read the rendered DOM instead — not to conclude anything.

4. robots.txt, which tells you what exists

This one is under-used and it costs one request.

curl -s https://example.com/robots.txt

Disallow lines are a list of things the site owner knows about and would rather you did not crawl. That is a site map of sorts, drawn by someone with full knowledge.

A concrete example. I was evaluating a service to see whether their listings link back to the products they list. Their robots.txt disallowed /provider/ and /developer/ — which told me those sections existed, that they were considered low-value, and that whatever lives there is not meant to be indexed. Combined with the listing page carrying no outbound link at all, the picture was complete in about four minutes.

The lie: robots.txt is a request, not a wall. Paths listed there are frequently still reachable and sometimes still indexed. It tells you about intent, not access.

Putting it in order

For a site you know nothing about, this is about five minutes:

curl -sI — status, server, CDN, redirect chain
curl -s .../robots.txt — what exists, what they hide
dig MX and dig TXT — real mail host, and every SaaS they pay for
Page source for generator and /wp-content/ — the CMS
If the source is thin, open devtools and read the rendered DOM

And the corresponding list of what each one cannot tell you, which is the part worth memorising:

Check	Confidently wrong about
A record	the origin, whenever a CDN is in front
Response headers	the origin, again — it is the edge answering
Raw HTML	anything rendered client-side
robots.txt	what is actually reachable

None of these are exotic failure modes. They are the normal case on any site built in the last five years, which is why the checks are worth running together rather than one at a time. Each one covers the specific blind spot of another.

The version of this I keep having to relearn: a check that returns cleanly has not necessarily answered your question. It has answered its question, and it is on you to know whether that was the one you asked.

I build Utilorax, a set of free browser-based tools — the ones linked above among them. They exist because I got tired of not having a terminal handy on someone else's laptop.

I found 216 missing translations. There were 55.

Hammad Shams Uddin — Tue, 11 Aug 2026 16:26:19 +0000

I run a site with about 6,000 pages across five languages. Last week I went looking for interface strings that had never been translated — the labels on form fields, the options in a dropdown, the text on a button.

I wrote a script. It walked the tool registry, collected every input_label, every option label, every placeholder, every select choice, and diffed that set against the Spanish translation catalogue.

216 missing.

I spent the evening writing translations for all of them, in four languages.

They were not missing.

Two dictionaries

The site has two translation catalogues, and I had forgotten there were two.

data/i18n/{lang}/tool-labels.php     read by the PHP view
data/i18n/{lang}/widget-labels.php   shipped to the browser as JSON

The first one is for strings the server renders into the HTML — form labels, buttons, the options inside a <select>. The second is for strings the JavaScript builds at runtime, after the page has loaded: the word "Copy" on a copy button, a result label that only exists once you've clicked something.

They exist separately for a boring, correct reason. The second one gets serialised into every page as a <script> blob, so it holds only what the browser genuinely needs. Putting the server-side labels in there would ship a few hundred strings to every visitor for nothing.

I diffed against the second one. The view reads the first.

The real gap was 55 strings, and the mechanism that filled them had existed and worked for months.

Every step was defensible

This is the part I keep turning over.

Nothing I did was sloppy. I read the registry that defines the tools. I read the catalogue that holds the translations. I wrote a set difference. I sorted the output and eyeballed it, and the strings in it were plainly English — Cost factor, Background color, Algorithm — which is exactly what a missing translation looks like.

At no point did the evidence contradict itself. The numbers agreed with each other all the way down, because they were all answering the same wrong question: is this string in that file?

The question I actually had was: does a Spanish visitor see this in Spanish?

One HTTP request would have answered it:

curl -s https://example.com/es/documents/rotate-pdf | grep -o '<label[^>]*>[^<]*'

Rotación. 90° en sentido horario. Already there, in the first minute, instead of the fourth hour.

It got worse before it got better

Having "found" the gap, I fixed it — by changing the view to look strings up in the JavaScript dictionary as well.

That looked like it worked. Pages rendered, labels appeared, nothing broke.

What it actually did was give the application two dictionaries answering the same question, and they did not agree. The English string Order was translated as 顺序 in one and 排序 in the other. Both are correct Chinese. Which one a visitor saw came down to which lookup ran first — an accident of the order of two lines in a template.

I only caught it because a page showed me 顺序 while the file I had just edited said 排序, and those two facts could not both be true.

That is the second lesson hiding inside the first: a fix built on a wrong diagnosis does not fail loudly. It produces a system that works and is wrong, which is considerably harder to find later.

The same week, twice more

Once you have a name for a mistake you start seeing it.

Two new pages, no internal links. I added two tools to the site and checked whether anything linked to them, by reading the related arrays in the data file. Zero. I was about to spend an hour adding links by hand when I loaded one of the existing pages instead. The links were already there — the registry's helper pads a short related list with other tools from the same category, and every page in that category already pointed at the new ones.

A backlink that does not exist. I was about to submit the site's API to a directory, and the question I set out to answer was whether their listing gives a dofollow or a nofollow link. I fetched a real listing page. 230 KB of HTML, and not one link to the provider's own site. The provider's domain does not appear anywhere on the page. Their profile URL 404s. robots.txt disallows the whole /provider/ path.

The question was not dofollow-or-nofollow. There is no link. I had spent my effort on a refinement of a premise I never checked.

What I actually learned

The tempting lesson is "always verify manually," and that is both true and useless — you cannot manually verify everything, and reading files is how most work gets done.

The useful version is narrower:

Every question has an artifact that is the ground truth for it, and it is often not the artifact you are already holding.

Is this string in the catalogue? → the catalogue is ground truth. Read the file.
Does the user see this translated? → the rendered page is ground truth. Read the page.
Does this page link to that one? → the rendered page, not the config that generates it.
Does this site give me a link? → their rendered page, not their marketing copy about their programme.

The failure in all three cases was substituting a source that was upstream of the truth for the truth itself. Upstream sources are seductive because they are structured, greppable, and fast. The rendered page is none of those things, which is exactly why it is the one that settles arguments.

A cheap habit that would have caught all three: before writing the script that measures the thing, load the thing once and look at it. Not as a test — as a sanity check on what you are about to spend the evening measuring.

Fifty-five strings needed translating. I found that out the second time.

I build Utilorax, a set of free browser-based tools. It is five languages deep, which is how you end up with two translation dictionaries and forget one of them exists.

Google said 51 pages were excluded by noindex. Here's how I checked in ten minutes.

Hammad Shams Uddin — Sat, 08 Aug 2026 11:38:29 +0000

Two emails from Search Console arrived the same morning. The first was the one that worried me:

New reasons prevent pages in a sitemap from being indexed on site utilorax.com
Excluded by 'noindex' tag

Read that carefully. Pages in a sitemap — pages I am explicitly asking Google to index — are being skipped because they carry a noindex. That is a contradiction, and it is the kind that quietly costs you: the sitemap says "index this", the page says "don't", and Google believes the page.

Fifty-one of them. My site has around 6,000 URLs across five languages, so 51 was small enough to be a real bug and large enough to matter.

Here is how I found out whether it was one, without opening 51 URLs by hand.

The method: sample by URL shape, not at random

Random sampling is the wrong tool here. A noindex bug is almost never random — it comes from a template, a route, or a language variant, so it affects a whole class of URLs. If you sample 50 URLs out of 6,000 at random you will probably miss a class of 51. If you sample one URL from every distinct shape, you cannot.

So:

1. Collect every URL the sitemaps actually claim. Not what you think you publish — what the XML says today.

curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed 's|</\?loc>||g' > maps.txt

while read m; do
  curl -s --retry 2 "$m" | grep -o '<loc>[^<]*</loc>' | sed 's|</\?loc>||g'
done < maps.txt | sort -u > allurls.txt

That gave me 5,881 URLs across 54 sitemap files.

2. Reduce them to shapes. Strip the language prefix, keep the first path segment, mark anything deeper with a wildcard. /es/convert/miles-to-km and /es/convert/kg-to-lb are the same shape; /es/blog/some-post is a different one.

5,881 URLs collapsed into 101 distinct shapes — en /convert/*, es /convert/*, fr /tools/*, en /about, and so on.

3. Fetch one of each and check both places a noindex can hide. This is the step people get wrong: they check the HTML meta tag and forget the header, or the reverse.

while read u; do
  H=$(curl -s -m 30 -D - -o body.html "$u")
  XR=$(echo "$H" | grep -i "^x-robots-tag")
  MR=$(grep -o '<meta name="robots" content="[^"]*"' body.html | head -1)
  if echo "$XR $MR" | grep -qi "noindex"; then echo "HIT: $u"; fi
done < sample.txt

Result: 101 out of 101 returned 200, and not one carried a noindex — in the header or in the markup. No contradiction. The sitemap and the robots directives agreed everywhere.

Ten minutes, and the scary email was answered.

So what were the 51?

Once the sitemap was cleared, the answer had to be pages Google found some other way — through internal links, old crawls, or the wider web. Grepping my own routing for every place that sets a noindex gave the list immediately:

/api/* — JSON endpoints
/cron/* — scheduled jobs
/dl/* — file downloads
/developers/* — logged-in account pages
and eight pages I had to work out: the es, fr, pt and zh versions of /refund and /terms, which have no translation and are deliberately noindex outside English until someone writes one

Every one of them is noindex on purpose. Google was not reporting a bug. It was reporting a fact, in a message worded strongly enough to look like a bug.

That is the part worth keeping. "Excluded by 'noindex' tag" is not an error. It is Search Console telling you what it found, and on any site with an admin area, an API or logged-in pages, a non-zero number there is correct and healthy. The number to react to is not the count — it is whether any of those URLs are ones you wanted indexed.

The other number I had been reading wrong for a week

While I was in there, the Page Indexing report finished processing for the first time since launch. It said:

Indexed        3,040
Not indexed    3,237
Total known    6,277        ->  48.4% indexed

My notes said 12%.

That figure had come from the HTTPS report, which showed 728 URLs at a time when the indexing report was stuck on "processing". I had divided 728 by my sitemap total and written down "only 12% is indexed, so indexing is the bottleneck" — and then let that sentence drive my priorities for a week.

The HTTPS report counts URLs whose HTTPS status Google evaluated. It is a sample. It was never the index size, and it never claimed to be. I had made it answer a question it was not asked.

Half of a twelve-day-old site being indexed is not a bottleneck. It is fine. The actual bottleneck was somewhere else entirely, and I had spent a week not looking at it.

The one that was genuinely worth opening

The bigger bucket was "Crawled — currently not indexed": 215 pages. That one means Google fetched the page, read it, and decided against it — which is a judgement, not a mechanic, and worth understanding.

I pulled the full list and counted it rather than eyeballing the examples:


Non-English	97% (es 38%, fr 35%, pt 23%)
`/convert/*` pages	71%

So: non-English converter pages, almost exclusively.

The obvious theory is thin or machine-translated content. I tested it by comparing a Spanish page against its English counterpart word by word — they share only 17–21% of their vocabulary and each runs about 1,000 words. The translations are real.

What I did find was worse in a subtler way: three places built an English sentence and dropped translated nouns into the gaps. The breadcrumb read "Caballos de Fuerza to Vatios". Related cards read "Convert Caballos de Fuerza to Kilovatios instantly." Eleven English fragments per page, on every converter, in four languages.

That is a genuine quality bug and I fixed it. But I want to be honest about what fixing it does, because the temptation is to declare victory: it is almost certainly not why those pages were skipped. A twelve-day-old domain with zero external links does not get unlimited index budget, and non-English pages of a site nobody has ever linked to are the first thing dropped. That is an authority problem. No amount of copy editing fixes it — links and time do.

What I would tell myself a week ago

Sample by URL shape, not at random. Template bugs affect classes, so test classes.
Check the header and the meta tag. A noindex can live in either, and the report does not tell you which.
"Excluded by noindex" is usually correct. Verify it is only hitting things you meant.
Never infer one report's number from another's. The HTTPS report is not the index count. A number that is roughly the right shape is the easiest kind of wrong to keep believing.
When you find a real bug during an investigation, do not let it become the answer. It felt like the cause. It was not.

I build Utilorax, a set of free browser-based tools. Everything runs client-side, which produces a steady supply of problems like this one.

Parallel connections made my speed test 2x slower

Hammad Shams Uddin — Sat, 08 Aug 2026 10:18:06 +0000

I built a speed test last week. It told me my download was 8.2 Mbps. Speedtest.net, on the same line, five minutes later, said 28.65.

My first instinct was that this was a distance problem, and I had a good reason to think so. Speedtest.net had picked a PTCL server in Karachi — same city, 3 ms away. Mine measures to whichever Cloudflare edge answers, and from here that is Singapore, 120 ms away. Of course a server on another continent reads lower.

That explanation was comfortable, it fit the numbers, and it was wrong.

The measurement that killed it

Before rewriting anything, I checked the assumption with curl. Same machine, same file, same Cloudflare edge, all within a minute of each other:

how the file was fetched	throughput
one connection at a time, sequentially	19.2 Mbps
six parallel connections	11.1 Mbps
my speed test, eight HTTP/2 streams	8.2 Mbps

The path was capable of 19 Mbps. My tool was reporting 8. And the more connections I opened, the worse it got — the exact opposite of what I had built the thing to assume.

Why I had it backwards

Every guide on measuring bandwidth says the same thing, and it is not wrong: a single TCP connection often cannot fill a long fat pipe. Throughput per connection is bounded by the congestion window divided by the round trip time, so on a 120 ms path one connection tops out well below the line rate no matter how fast the line is. Open several and you fill the pipe.

I had believed this hard enough that, an hour before running that curl test, I had tuned the default from six streams to eight — reasoning that a long path needs more parallelism. I made it worse and felt clever doing it.

What that advice omits is that it assumes spare capacity. Parallel connections do not politely share a fixed pot of bandwidth; each one runs its own congestion control and pushes until it sees loss. On an uncongested path they ramp independently and add up. On a path that is already the bottleneck — an oversubscribed international link, in my case — they push it into loss together, every one of them backs off, and the aggregate collapses below what a single well-behaved connection was getting.

Both behaviours are real. Which one you get depends on the path, and you cannot know which from the client.

So stop guessing and measure it

The fix was to stop picking a number. The download phase now runs twice — once with two connections, once with eight — and reports whichever went faster, showing both.

On my line, live:

2 connections : 15.1 Mbps
8 connections :  5.18 Mbps

Same file, same run, ninety seconds apart. Three times the difference, purely from concurrency.

The reported download went from 8.2 to 15.1 Mbps. Still below Ookla's 28, and I will come back to why, but it is now measuring the connection rather than measuring my assumption about the connection.

Two ways I rigged my own experiment

The first version of that A/B was not a fair test, in two ways that are worth naming because both are easy to repeat.

The second segment inherited the first one's congestion. Five seconds of saturated download leaves queues full along the path. Starting the next measurement immediately measures the tail of the previous one, which makes whichever segment ran second look worse regardless of what it was doing. There is now a 600 ms drain between them.

The second segment got half the warm-up. I had reasoned that the connection was already open and warm, so it needed less time to ramp. True of the connection — false of the six additional streams, which each start at a small congestion window and need the same number of round trips to open up. I was counting their ramp as their speed. Both segments now get the same warm-up.

That warm-up is itself scaled to the measured ping rather than fixed, for the same reason: slow start doubles the congestion window once per round trip, so the time a connection needs to reach full speed is counted in RTTs, not seconds. A flat 1.4 seconds is generous on a 10 ms link and far too short on a 120 ms one.

What I could not fix

The remaining gap against Ookla is genuinely the path, and I checked that too rather than assuming it a second time.

speed.cloudflare.com gets 24.7 Mbps from this machine — because Cloudflare serves it from their Karachi edge. My site is served from Singapore. Same CDN, same city, different datacentre, and which one answers is Cloudflare's routing, not something a site owner sets.

So the honest position is that both numbers are true and they are answers to different questions. Ookla's 28 is roughly the best this line does to a server inside the same ISP. My 15 is roughly what it does to a service hosted abroad — which, for most of what people actually load, is the more relevant number. The tool now says so on screen when the round trip is over 80 ms, instead of leaving people to conclude it is broken.

Three smaller things that also decide whether the number means anything

The payload has to be incompressible. A file of zeros gets compressed in transit, so the browser receives a few kilobytes, inflates them, and reports a connection hundreds of times faster than it is. Random bytes, and I check the generated file's own compressibility rather than trusting the RNG.

The file extension decides whether it is edge-cached. I measured this rather than reading it: on my domain, .bin, .zip, .gz, .jpg and .woff2 come back cf-cache-status: HIT, while .dat, .br and .wasm come back DYNAMIC. A DYNAMIC payload means every request travels to the origin, so you end up measuring a shared host in one fixed country instead of the user's path to the edge — and paying for the bandwidth.

xhr.upload.onprogress does not measure the wire. It fires when data enters the operating system's send buffer, which swallows several megabytes instantly. Mine reported a 90 Mbps "peak" beside a 26 Mbps average on the same eight seconds. Nobody reading those two numbers concludes they were measured differently; they conclude the tool is broken. Every upload figure now comes from byte counts the server confirms receiving.

The takeaway

The advice that more connections are faster is correct often enough to be repeated everywhere and to sound like a law. It is a heuristic about one common case, and on a congested path it inverts completely.

If you are measuring throughput, the general form of the lesson is worth more than the specific finding: when a parameter's correct value depends on conditions you cannot observe from your side, measure both and keep the winner. It costs one extra segment and removes an assumption that was silently halving my results.

The test is here if you want to see the two-segment result on your own line — it shows both figures, so you can see which way your path leans.

I build Utilorax, a set of free browser-based tools. Everything runs client-side, which produces a steady supply of problems like this one.

ffmpeg.wasm 0.12 hung on the first frame — and the real speedup was not the upgrade

Hammad Shams Uddin — Thu, 06 Aug 2026 22:08:19 +0000

I run Utilorax, a set of free browser-based tools. The video tools are ffmpeg.wasm, which means every encode runs on the user's own machine and nothing is ever uploaded. That is the whole point of them — and it is also why they were slow.

This is what a week of trying to fix that actually taught me. The upgrade I was sure would fix it did not, and the thing that did was much less interesting and much more effective.

The starting point: one core

Every encode was pinned to a single thread:

function pinThreads(args) {
  var body = args.slice(0, -1), out = args[args.length - 1];
  return ['-threads', '1'].concat(body, ['-threads', '1', out]);
}

That looks like an oversight. The core is the multi-threaded build, ffmpeg-core.worker.js ships with it, and the page already pays for COOP/COEP so SharedArrayBuffer is available. Letting ffmpeg use every core looks like free speed.

It is not. Take the pin off on ffmpeg.wasm 0.11 and the video filter dies instantly with RuntimeError: function signature mismatch thrown out of worker.js onmessage — a known 0.11 fault where the threaded core trips over its own dynCall table. Nothing renders. 0%.

So the encoder ran on one core on machines that have eight. A 1080p60 clip filtered at about 0.09× real time. 0.12 fixed the threading fault, so 0.12 was obviously the answer.

Upgrading to 0.12: three things nobody mentions

The API changed shape, not just names — run() became exec(), the FS() calls became methods, fetchFile moved package, and everything returns a promise. Rather than rewrite sixty-one call sites twice (once to port, once to revert if it went wrong) I put an adapter in front that presents the 0.11 surface on top of 0.12. That part went fine.

Then the interesting failures started.

1. The UMD bundle is not self-contained

@ffmpeg/ffmpeg's UMD build loads its own worker as a separate webpack chunk, 814.ffmpeg.js, from whatever directory ffmpeg.js came from. It is not in the docs and it is not obvious — you just get a 404 and a load() that never resolves. Ship it alongside ffmpeg.js.

2. `classWorkerURL` looks like the fix for that. It is a trap.

Passing it sends the UMD build down its ESM branch:

load = ({classWorkerURL: s, ...r} = {}) =>
  this.#e || (this.#e = s
    ? new Worker(new URL(s, "file:///home/jeromewu/…"), {type: "module"})   // ← ESM branch
    : new Worker(new URL(e.p + e.u(814), e.b), {type: undefined}))          // ← classic

A module worker — around a chunk that is a classic script calling importScripts(). It dies on load. Leaving the option out is what makes it work.

3. Workers need the COEP header on themselves

A cross-origin-isolated page will refuse a worker script unless that script's own response carries Cross-Origin-Embedder-Policy: require-corp. Same-origin is not enough. Apache sends nothing on a static file, so the whole chain fails: the class worker, the core it importScripts, and the pthread workers Emscripten spawns.

<If "%{REQUEST_URI} =~ m#/js/vendor/ffmpeg-012/#">
    Header set Cross-Origin-Embedder-Policy "require-corp"
    Header set Cross-Origin-Resource-Policy "same-origin"
</If>

0.11 never needed this because it builds its worker from a blob URL, and a blob inherits the page's policies instead of being checked for headers. That is a difference in how the worker is created, not in the API — you will not find it by reading the diff.

One more: keep your service worker away from those files. It caches whatever headers an entry had when it was written, so one fetch made before the header rule existed gets served back forever, and it surfaces as a COEP error pointing at the worker rather than at the cache.

Then it hung on the first frame

Headers fixed, pin removed, and the filter printed exactly one line:

frame=    1 fps=0.0 q=0.0 size= 0kB time=00:00:00.14 bitrate= 2.6kbits/s speed=2.04x

and then nothing. No error. 0% forever.

The core pre-allocates exactly 32 pthread workers and cannot grow past them here:

getNewWorker: function () {
  if (PThread.unusedWorkers.length == 0) {
    PThread.allocateUnusedWorker();
    PThread.loadWasmModuleToWorker(PThread.unusedWorkers[0]);  // ← async
  }
  …
}

Growing the pool means loading the module into a fresh worker and waiting for it to answer — but ffmpeg runs synchronously inside the very worker that would have to process that answer. The thread it is blocked on can never start. Ask for a 33rd and everything stops, silently.

Left to itself ffmpeg asks for far more than 32. It spends threads in three places at once: one set per input decoder, one for the filter graph, and x264 takes 1.5 per core on top. On anything with nine or more logical cores you are already over the line — which is why this only appears once the pin comes off.

So: give each stage an explicit budget instead of the machine's core count.

var THREADS = Math.max(1, Math.min(4, navigator.hardwareConcurrency || 4));
// worst case ≈ (inputs + 2) × THREADS — a 5-clip merge at 4 is already 28 of the 32
['-threads', n, '-filter_threads', n, '-filter_complex_threads', n]
  .concat(body, ['-threads', n, out]);

-filter_threads matters more than it looks. It is a global option and defaults to one thread per core on its own, which was most of the overspend.

The error that ate its own error message

Two ops aborted instead of hanging, and every one of them reported:

TypeError: Cannot read properties of undefined (reading 'startsWith')

That is not your bug. It is the core's own error handler:

try { Module["_ffmpeg"](args.length, stringsToPtr(args)) }
catch (e) { if (!e.message.startsWith("Aborted")) { throw e } }

e is not always an Error. When it isn't, e.message is undefined, and the handler throws while inspecting the crash — so whatever ffmpeg actually said is lost. If you see that string, the real failure is upstream and you cannot see it.

What I actually shipped

I put the tools back on 0.11.

Not because 0.12 is bad, but because the premise was wrong. 0.12 is worth a few times one core. A 6-minute 1080p60 clip is about 21,000 frames, and software x264 in wasm will not get through that quickly at any thread count. I was optimising the wrong axis.

The real win was not running the encoder at all.

Container conversion — MKV→MP4 and friends are the same H.264 in a different box. -c copy instead of decode-and-re-encode: seconds, and no second round of lossy compression. Judge the output, not the promise — ffmpeg.wasm resolves even when ffmpeg gave up, so try the copy and fall back if the file is missing or tiny. Trying the copy is the probe, and it is cheaper than the transcode it replaces.
Rotate — a quarter turn is a flag on the video track, not a change to the pixels. Stream copy plus -metadata:s:v:0 rotate=90.
Trim — copy the streams instead of rebuilding them. The cut then lands on a keyframe, so it is a real trade rather than a free win: make it a checkbox.

Rotate has a catch worth knowing. The risk is not that the copy fails, it is that it silently does nothing: phone footage often already carries a rotation, and when the streams are copied that existing flag can survive and override the one you set. The file comes out perfectly valid, and unturned. So measure the output rather than trusting it — a <video> applies a container's rotation when it reports videoWidth, so a turn that worked has the sides swapped:

function displayedSize(data, mime) {
  return new Promise(function (resolve) {
    var url = URL.createObjectURL(new Blob([data.buffer], {type: mime}));
    var v = document.createElement('video'), done = false;
    var settle = function (r) { if (!done) { done = true; URL.revokeObjectURL(url); resolve(r); } };
    setTimeout(function () { settle(null); }, 8000);   // an answer that never comes is the freeze you were avoiding
    v.onloadedmetadata = function () { settle({w: v.videoWidth, h: v.videoHeight}); };
    v.onerror = function () { settle(null); };
    v.src = url;
  });
}

No swap, no proof, re-encode.

What I would tell myself a week ago

Threads were the interesting problem. Not encoding was the useful one. The ops that got fast — convert, rotate, trim, mute — got fast because they stopped doing work, not because they did it on more cores.

And when the number of threads is the thing you are tuning, check what the runtime can actually give you before you ask for more. A pool of 32 that cannot grow is a hard ceiling, and the failure mode is a silent hang rather than an error — which is a bad way to find the edge.

For the ops that genuinely must decode every frame — filters, resize, compress — wasm is still wasm, and the next honest step is WebCodecs and the hardware encoder. That is a different post.

DEV Community: Hammad Shams Uddin

You cannot round three numbers that have to add up to a fourth

Why rounding each one cannot work

The weights are 4, 4 and 9

The first version was still wrong, and quietly

Testing it

And say the number

A missing exchange rate is not an exchange rate of 1

What || 1 means here

The second one, in the same function

The shape

The part that makes it embarrassing

The fixes

Testing a feed that has failed

Your amortisation schedule is one row short, and only sometimes

The line

What it costs

Why it survived

The fix is one line and one consequence

The same mistake, upstairs

Tests a borrower could run

I made twenty tools take twenty files. Every bug was state that outlived one file.

Bug one: the second file overwrote the first

Bug two: the array that was empty for the whole run

Bug three: an operation completing is not evidence it did anything

Sequential, not Promise.all

How I actually found these

The file existed, so I assumed the check passed

What the tool does

The check

Why it survived

The fix is to ask the actual question

Testing something that only runs in a browser

The general version

Two scrolling panes is the wrong way to build a side-by-side diff

Start with the diff you already have

Problem one: an edited line is two entries

Problem two: the eye still has to re-read both lines

Problem three: two scrolling panes is a trap

The bit that only shows up on a phone

Worth testing, and easy to

Working out what a site is running — and where every check lies to you

1. DNS, and the CDN that hides everything behind it

2. Response headers, which are honest by accident

3. The HTML, which is where the CMS gives itself away

4. robots.txt, which tells you what exists

Putting it in order

I found 216 missing translations. There were 55.

Two dictionaries

Every step was defensible

It got worse before it got better

The same week, twice more

What I actually learned

Google said 51 pages were excluded by noindex. Here's how I checked in ten minutes.

The method: sample by URL shape, not at random

So what were the 51?

The other number I had been reading wrong for a week

The one that was genuinely worth opening

What I would tell myself a week ago

Parallel connections made my speed test 2x slower

The measurement that killed it

Why I had it backwards

So stop guessing and measure it

Two ways I rigged my own experiment

What I could not fix

Three smaller things that also decide whether the number means anything

The takeaway

ffmpeg.wasm 0.12 hung on the first frame — and the real speedup was not the upgrade

The starting point: one core

Upgrading to 0.12: three things nobody mentions

1. The UMD bundle is not self-contained

2. classWorkerURL looks like the fix for that. It is a trap.

3. Workers need the COEP header on themselves

Then it hung on the first frame

The error that ate its own error message

What I actually shipped

What I would tell myself a week ago

What `|| 1` means here

2. `classWorkerURL` looks like the fix for that. It is a trap.