DEV Community: Convertilo

In-browser machine translation: I measured 30 phrases, found 30% wrong in meaning, and changed the engine

Convertilo — Wed, 30 Sep 2026 22:30:05 +0000

Our free translator ran a small machine-translation model directly in the browser (a Bergamot / Opus-MT style model compiled to WebAssembly). The appeal is privacy: the text never leaves the device. The downside is quality. I finally stopped guessing and measured it on the live site with 30 phrases.

The test

30 phrases in both directions between English and Russian, grouped by type. I marked each result as correct, correct with small flaws, or wrong in meaning.

Result: 43% correct, 26% with small flaws, 30% with a changed meaning. Speed was fine: the first translation takes about 11 s (model download and load), after that about 1.7 s per phrase.

What worked and what did not:

Connected prose and business text: good, in both directions.
Technical text: it invented words ("driver" became "водитель" (a vehicle driver) instead of a software driver).
Idioms and casual speech: 5 out of 5 failed. "I'll hit you up" came out as "I will hit you", which reads as a threat.
Ambiguity: "the bank refused the loan" was inverted.
A legal sentence, "shall not disclose ... to any third party", came out with the direction of the prohibition reversed. For a translator that advertises use on contracts, that was the one that worried me most.

The pattern is simple: it fails exactly on what a random visitor tries first, an idiom or a casual phrase.

Trying LLMs as a replacement

I ran the same 30 phrases through 8 models over an API (240 requests). The whole benchmark cost about $0.013. The hard set was 17 phrases where the in-browser model had failed.

Model	Hard phrases right (of 17)	Median latency
Gemma 26B (instruction-tuned)	17	1.46 s
GPT-5.4 mini	15	1.06 s
Llama 3.3 70B	13	0.92 s
DeepSeek V4 Flash	13 (+2 empty)	2.85 s
Qwen3 30B A3B	11	1.96 s

Two things surprised me:

The cheapest model was the worst. Qwen3 30B had the lowest price and the lowest score. It translated "Klöße" as cutlets and "Vorspeisen" as first courses. "Newer and bigger" is not the same as "better for this task"; I had bet on Qwen before measuring and was wrong.
Reasoning models are a trap for translation. One of them returned empty text for all 30 phrases, because it spent the whole token budget on thinking and never reached the answer. Raising the limit just means paying for the most expensive tokens.

I shipped the winner. The cost came out to roughly $0.16 per million source characters, and it fixed the threatening "hit you" case and the inverted legal sentence.

The trade-off I had to accept

Moving translation to a server model means the text now leaves the device, which was the original selling point. The client falls back to the local model if the server call fails. If privacy is your main constraint, the small local model is still the right tool. If quality on everyday text matters more, it is not good enough.

You can compare for yourself: the browser translator and the English to Russian page. What phrases break your favourite translator?

TensorFlow.js in the browser: why one new tensor shape cost 8-17 seconds, and how I cut a 40 s freeze

Convertilo — Wed, 30 Sep 2026 22:17:52 +0000

I run a photo enhancer that does super-resolution fully in the browser: TensorFlow.js on WebGL, nothing is uploaded. The first version used the upscaler library (UpscalerJS). On a 1.2 megapixel photo it took 60-110 seconds and froze the page for about 40 seconds. A user told me "it does not accept any of my photos", which was partly a bad 0.6 MP limit on my side and partly the freeze. Here is what I found while fixing it. Most of it applies to any browser-side ML on WebGL.

1. Every new tensor shape recompiles the shaders

tfjs compiles WebGL programs per operation and per tensor shape. On my machine (an M2 Max) one new shape cost 8-17 seconds of shader compilation. The killer was the edge tiles: I cut the image into tiles, and the last row and column had a different size, so the model was compiled again for them.

What fixed it:

Make every tile exactly the same shape. Pad the image once to a whole number of tiles instead of handling a smaller remainder.
Set WEBGL_USE_SHAPES_UNIFORMS=true so shapes are passed as uniforms and programs can be reused across shapes.

2. Compilation is synchronous and blocks the page

Even with the same shape, the first compile blocks the main thread. tfjs 4.11 has a way to compile ahead of time without running the model: use ENGINE_COMPILE_ONLY, then backend.checkCompileCompletionAsync() and getUniformLocations(). That moves the wait out of a frozen page and lets you show a progress state.

3. im2col convolutions can eat your video memory

The default convolution path uses im2col. For a 5x5 kernel with 64 channels on a 280x280 tile it needed about 500 MB of GPU memory in my case. Setting WEBGL_CONV_IM2COL=false gave the same speed with a peak of roughly 100-200 MB. That is the difference between working on a phone and crashing the tab.

4. Smaller things that mattered

tfjs keeps freed textures around. Set WEBGL_DELETE_TEXTURE_THRESHOLD so the pool does not grow without limit.
Read each result tile with await tf.browser.toPixels(...) and draw it on a canvas straight away. Do not stitch tensors together and do not go through base64.
upscaler.js never gives control back to the browser without awaitNextFrame, and with it it gets even slower. I dropped the wrapper and load the model directly with tf.loadLayersModel.

Numbers after the fix

Input	Time
1 MP photo	4-7 s
12 MP photo (downscaled to 4 MP input, 16 MP output)	16-24 s

The 16 MP output is the ceiling because of the canvas size limit on iOS. I have not tested low-end devices yet, so treat these numbers as "a recent laptop".

If you want to try the result, the photo enhancer is live (the interface is in Russian, but the upload and result are self-explanatory). Has anyone else measured shader compile time on other GPUs?

Implementing the Destiny Matrix in TypeScript: reducing a birth date to Major Arcana

Convertilo — Wed, 30 Sep 2026 20:22:42 +0000

The "Destiny Matrix" is a numerology-style system that went viral on social media: you enter a birth date and get a chart of numbers from 1 to 22, each one mapped to a Major Arcana card. To be clear up front, it is a tradition and entertainment, not science. But the calculation itself is a nice small algorithm problem, and most online explanations are vague about it. Here is the exact logic I use in a free calculator, in TypeScript.

Step 1: reduce any number to 1..22

Everything is built on one helper. Keep summing the digits until the value is 22 or less. The only special case is zero, which becomes 22 (the last arcana, the Fool).

export function reduceArcana(n: number): number {
  let v = Math.abs(Math.trunc(n))
  while (v > 22) {
    v = String(v).split('').reduce((s, d) => s + Number(d), 0)
  }
  return v === 0 ? 22 : v
}

export function sumDigits(n: number): number {
  return String(Math.abs(Math.trunc(n))).split('').reduce((s, d) => s + Number(d), 0)
}

Note that a value like 19 or 22 is left alone (it is already valid), while 29 becomes 11 and 36 becomes 9.

Step 2: the four main points

Take the day, month and year of birth:

left point a = reduceArcana(day)
top point b = reduceArcana(month)
right point c = reduceArcana(sumDigits(year))
bottom point d = reduceArcana(a + b + c)

The year is handled in two steps: first the digit sum (1990 gives 19), then the reduction to 1..22.

Step 3: center and corners

The center is the sum of all four main points, and the diagonal corners are sums of neighbours:

const center = reduceArcana(a + b + c + d)

const corners = {
  topLeft: reduceArcana(a + b),
  topRight: reduceArcana(b + c),
  bottomRight: reduceArcana(c + d),
  bottomLeft: reduceArcana(d + a),
}

A worked example

For 14 March 1990:

Point	Calculation	Value
left	14	14
top	3	3
right	1+9+9+0 = 19	19
bottom	14+3+19 = 36 -> 9	9
center	14+3+19+9 = 45 -> 9	9
top-left	14+3 = 17	17
top-right	3+19 = 22	22
bottom-right	19+9 = 28 -> 10	10
bottom-left	9+14 = 23 -> 5	5

Edge cases worth a unit test

29.11.2000: day 29 reduces to 11, month 11 stays 11, year 2000 gives digit sum 2. Bottom is 6 and center is 3.
01.01.2000: all small numbers, bottom 4, center 8.
A sum that lands exactly on 22 must stay 22, not become 4. This is the usual bug when people reduce with % 9.
Never reduce with modulo 9. It turns 18 into 0 and breaks the 10-22 range that the system needs.

Try it

If you just want to see the chart drawn for a date, the destiny matrix calculator uses exactly the functions above and runs fully in the browser, so the birth date never leaves your device.

ffmpeg.wasm: "memory access out of bounds" is usually not about memory (and 4 more slideshow gotchas)

Convertilo — Wed, 30 Sep 2026 20:20:19 +0000

I spent three iterations getting a browser-only "photos to video" tool working on top of ffmpeg.wasm. Everything runs client-side, nothing is uploaded. Most of the time went into five things that the docs and error messages don't tell you. Sharing them in case they save you an evening.

If you want to see the result, it is a free photo slideshow maker that builds the MP4 in your tab.

1. `memory access out of bounds` is just how an abort looks from outside

When the ffmpeg core crashes, the error that reaches JavaScript is RuntimeError: memory access out of bounds. It looks like an out-of-memory problem. In my case it never was. Any abort inside the core is reported this way.

The real reason is only in the engine's own log. Attach a log handler before you run anything:

ffmpeg.on('log', ({ message }) => console.debug('[ffmpeg]', message))

Without that, you are guessing. With it, the next two items took minutes instead of hours.

2. The `image2` muxer needs `-update 1` for a single image

If you write one frame to disk (for example to extract a poster), image2 treats the output name as a sequence pattern and fails. Add -update 1:

ffmpeg -i in.mp4 -frames:v 1 -update 1 poster.jpg

3. Prepare frames on a canvas, not in ffmpeg

My first version pushed every photo through ffmpeg for scaling and letterboxing. After fixing 1 and 2 the core still crashed while writing images. Moving frame preparation to canvas turned out to be better on every axis:

one ffmpeg command instead of N+1;
noticeably faster;
createImageBitmap(file, { imageOrientation: 'from-image' }) applies the EXIF rotation for you, so phone photos are not sideways;
every frame has the same pixel format, so the concat step needs one codec only.

4. The "repeat the last file" trick can hurt

A classic recipe against a truncated final frame in the concat demuxer is to list the last file twice. In this build it gave the last photo double time: three frames at 2 s came out as 8 s instead of 6 s. Without the duplicate I measured 5.97 s and the last frame was held fully. Measure your own build before you copy a recipe.

5. Audio: `apad` plus `-shortest`, not just `-shortest`

If you add a music track, plain -shortest cuts the whole video to the length of the track (a 6 s slideshow with 3 s of music becomes 3 s). Pad the audio with silence and then let -shortest trim a long track to the video:

-af apad -shortest

Bonus: remux instead of re-encode when you can

For a format converter the biggest win was skipping the encode. When the source codec fits the target container, -c copy only rewrites the container. In my measurements a remux took about 0.14 s against 1.41 s for a re-encode on a small clip, and in the deployed video format converter it is roughly 0.6-0.7 s against 2.9-5.6 s. I still re-encode HEVC on purpose, because an MP4 with HEVC does not open everywhere.

What trips you up most with ffmpeg.wasm? I am curious whether others saw the same "out of bounds" masking.

I benchmarked 6 WASM image codecs in the browser. Here is what beats the server.

Convertilo — Tue, 19 May 2026 23:07:41 +0000

TL;DR

Modern WebAssembly codecs (MozJPEG, libavif, OxiPNG/imagequant, libwebp, gifsicle, SVGO) now run fast enough in the browser that you can ship a real image-compression tool without uploading anything to a server. I built one (convertilo.io) and benchmarked the codec mix on 100 real-world images. Results below — and a couple of surprises about what doesn't work.

Raw data + repo: github.com/convertilo/wasm-image-benchmarks

The setup

Corpus: 100 mixed real-world images (photos, screenshots, transparent PNGs, animated GIFs, vector icons)
Quality: 75 (sane default for lossy)
Environment: Chrome 130, M-series Mac, warm WASM cache
Median reduction (per-image variance is ~±15%)

Results

Format	Engine	Mode	Median size reduction
JPEG	MozJPEG (@jsquash/jpeg)	lossy q=75	−53%
PNG	imagequant + @jsquash/png	lossy palette	−75%
PNG	OxiPNG (@jsquash/png)	lossless	varies*
WebP	libwebp (@jsquash/webp)	lossy re-encode	−17%
AVIF	libavif (@jsquash/avif)	lossy q=75	−59%
GIF (static)	gifsicle-wasm-browser	lossy −O3	−75%
GIF (animated)	gifsicle-wasm-browser	lossy −O3	−27%
SVG	SVGO v4 browser bundle	lossless multipass	−42%

*OxiPNG depends on whether the input was already optimized — anything from 0% to 60%.

PNG via imagequant and JPEG via MozJPEG hit numbers competitive with server-side TinyPNG. That was the moment I stopped looking for a server.

What actually shipped this

@jsquash — Sam Sneddon's WASM bindings around mozjpeg, libwebp, libavif, OxiPNG, imagequant. Lazy-loaded per format so the bundle stays tiny: ~250 KB only when the user picks a real file.
gifsicle-wasm-browser — full gifsicle 1.92 CLI compiled to WASM. Preserves animation frames properly (more on this below).
SVGO v4 — works fine in the browser via the bundled svgo/browser import. No need for a server.

Three things that didn't work (and saved you the time)

imagequant for WebP/JPEG

imagequant gives PNG the −75% number, so my first instinct was "apply the same quantization to WebP/JPEG before encoding." It actively hurts there: the palette quantization introduces dithering noise that wrecks lossy entropy coding. WebP went from −17% to −12%.

Rule: imagequant for lossless palette PNG only. Don't cross-apply.

WebP knob-twisting

I sunk a few hours into method: 4, pass: 3, sns_strength: 75, use_sharp_yuv: 1 for libwebp. Total impact: <1% extra reduction on already-optimized WebPs. If you're re-encoding WebP that's been touched by another tool, you're squeezing a stone.

GIF via canvas/ImageData

I tried decoding GIF, processing as ImageData, re-encoding. Animation frame timings die in transit. Just use gifsicle as a File → File pipeline and pass -O3 --lossy=80 directly. Don't reimplement what's already a 30-year-old C tool.

The privacy-first angle

The reason I cared at all: image compressors historically upload your files. Receipts, IDs, family photos, contracts — your stuff sits on someone's server. With WASM you can run the same codecs (MozJPEG, libavif, OxiPNG) entirely in the user's tab. Nothing leaves the device.

I learned the hard way that this also requires not loading Yandex.Metrika or Google Analytics before consent, which is a whole other post. The codec part is the easy half.

Reproduce

git clone https://github.com/convertilo/wasm-image-benchmarks
cd wasm-image-benchmarks
# results.json has the medians I cite above
cat results.json

If you want a live implementation rather than a benchmark, all of these codecs are wired up at convertilo.io — drop a file in and watch network: no upload happens.

If you've squeezed more out of any of these (especially WebP — I'm convinced there's more there), I'd love the numbers. Drop a comment.