DEV Community: Lucian (LKB)

I built 12 chaos & physics simulations that run entirely in the browser (no backend, no libraries)

Lucian (LKB) — Sat, 22 Aug 2026 12:05:13 +0000

Over the last few weeks I built a small rack of physics simulations — 12 of them — that all run client-side in a single HTML file each. No backend, no WebGL frameworks, no build step you can't read. Just <canvas>, requestAnimationFrame, and the actual equations.

Here's the whole rack if you want to click around first: lkforge.com/tools/physics. Below I'll walk through the two I'm happiest with — reaction-diffusion and the Lorenz attractor — because they show two very different flavors of "simple local rule → surprising global behavior."

1. Reaction-diffusion: Turing patterns from two numbers per cell

The reaction-diffusion lab runs the Gray-Scott model: two virtual chemicals U and V sit on a grid, diffuse at different rates, and react via U + 2V → 3V. U is fed in; V is killed off. That's the entire model, and it reproduces spots, stripes, mazes, dividing cells and coral — the same short-range-activation / long-range-inhibition idea Alan Turing proposed in 1952 to explain animal coat patterns.

The core update, on a toroidal grid with a 9-point Laplacian:

var uu = u[c], vv = v[c];
var lapU = (u[W] + u[E] + u[N] + u[S]) * 0.2 +
           (u[NW] + u[NE] + u[SW] + u[SE]) * 0.05 - uu;
var lapV = (v[W] + v[E] + v[N] + v[S]) * 0.2 +
           (v[NW] + v[NE] + v[SW] + v[SE]) * 0.05 - vv;
var uvv = uu * vv * vv;
un[c] = uu + (Du * lapU - uvv + f * (1 - uu)) * dt;   // U: diffuse, react away, feed
vn[c] = vv + (Dv * lapV + uvv - (f + k) * vv) * dt;   // V: diffuse, react in, kill

Two things I learned the hard way:

The feed/kill pair (f, k) is everything. Small changes switch the whole regime — coral at (0.0545, 0.062), mitosis near (0.046, 0.063), spots at (0.030, 0.062). I ship these as presets so people don't land on a dead grid.
Seed with a noisy patch, not a solid disk. A solid blob tends to bloom once and then die back to uniform grey. Random speckle lets the pattern nucleate across an area and reach a stable steady state.

Rendering is a createImageData grid mapped through a small color lookup table, drawn to an offscreen canvas and scaled up with drawImage — cheap enough to run a 200×200 grid at 60fps with ~10 solver steps per frame.

2. The Lorenz attractor: determinism without predictability

The Lorenz lab integrates the 1963 Lorenz equations with fourth-order Runge-Kutta and draws the trajectory as a rotating, fading 3-D trail:

function lorenzDeriv(s) {
  var x = s[0], y = s[1], z = s[2];
  return [SIG * (y - x), x * (rho - z) - y, x * y - BETA * z];
}

The fun part is the butterfly effect made visible: start a second point 1e-3 away from the first, integrate both under the identical rule, and show the separation climbing. The two paths track together, then peel apart onto opposite wings of the attractor — neither ever leaving the shape, neither ever repeating. That's the whole point Edward Lorenz made when a rounded weather-model input (0.506127 → 0.506) sent his forecast somewhere unrecognizable.

A couple of implementation notes:

RK4, not Euler. Euler visibly distorts the attractor as the path stretches and folds; RK4 with a small dt keeps it honest.
Orthographic projection + one yaw/pitch rotation is enough — no full 3-D pipeline. Drag updates yaw/pitch; an auto-spin adds a constant yaw increment per frame.
The same engine also renders Rössler and Aizawa attractors by swapping the derivative function.

Why single-file, client-side?

Three reasons that turned out to matter:

Longevity. No server means nothing to keep alive; these will still run in five years.
Embeddable. Because each sim mounts on one canvas id and wires to controls by id, the exact same script drives the tool page and an /embed/ widget — drop it into a blog post with one iframe.
Readable. Anyone can view-source and see the actual physics, which is kind of the point for teaching material.

If you want to poke at the rest — falling sand, a double pendulum, the double-slit experiment, charged particles in a magnetic field, Conway's Game of Life — they're all here: lkforge.com/tools/physics.

Happy to answer questions about any of the models in the comments.

Watch a Game AI Think: Minimax and Alpha-Beta, in a Browser Tab

Lucian (LKB) — Wed, 19 Aug 2026 20:42:51 +0000

Every "AI" opponent in a board game — Tic-Tac-Toe, Connect 4, Checkers, Othello, Chess — tends to run the same idea: search the game tree, assume the opponent plays their best, and pick the move with the best guaranteed outcome. That idea is minimax, and alpha-beta pruning is what makes it fast enough to run in a browser tab with no backend.

I built an interactive version where you can step through minimax on a real board and toggle alpha-beta on to watch it skip work: play with it here. This post is the written companion.

Minimax in one function

Score a finished position from the AI's point of view: +1 if the AI wins, -1 if you win, 0 for a draw. Then walk the tree of possible futures. On the AI's turn it takes the max of its options; on your turn it assumes you take the min (the worst outcome for the AI). That alternation is the whole algorithm.

function minimax(node, isMax):
  if node is terminal:
    return score(node)          # +1 / -1 / 0
  if isMax:
    best = -inf
    for child in node.moves:    # AI's turn
      best = max(best, minimax(child, false))
    return best
  else:
    best = +inf
    for child in node.moves:    # your turn
      best = min(best, minimax(child, true))
    return best

Alpha-beta: same answer, fewer nodes

Searching every branch is wasteful. Once you've found a reply that already refutes a move, you don't need to look at that move's other branches — they can't change the decision. Two running bounds carry that knowledge down the tree: alpha (the best MAX can already guarantee) and beta (the best MIN can already guarantee). When they cross, you stop.

function ab(node, alpha, beta, isMax):
  if node is terminal:
    return score(node)
  if isMax:
    best = -inf
    for child in node.moves:
      best = max(best, ab(child, alpha, beta, false))
      alpha = max(alpha, best)
      if beta <= alpha: break   # prune the rest
    return best
  else:
    best = +inf
    for child in node.moves:
      best = min(best, ab(child, alpha, beta, true))
      beta = min(beta, best)
      if beta <= alpha: break   # prune the rest
    return best

Pruning never changes the value at the root — only how many nodes you touch to find it. On a small Tic-Tac-Toe position with three empty squares, the full tree is 14 nodes and alpha-beta visits 10 of them. On the full-depth opening move it's dramatic: 549,945 nodes drop to 36,528 — a 93% cut — which is what lets a provably-unbeatable Tic-Tac-Toe move resolve in about 0.3 ms client-side. (The measured benchmarks are here.)

Why "just search deeper" gets expensive

A search that looks d moves ahead visits roughly b^d nodes, where b is the branching factor — how many moves you typically have. That number explodes:

Tic-Tac-Toe: b ≈ 4
Connect 4: b ≈ 4 (max 7 columns)
Checkers: b ≈ 2.8
Othello: b ≈ 10
Chess: b ≈ 35

Looking just 8 moves ahead in chess is on the order of 35^8 ≈ 2.3 trillion positions. Alpha-beta — plus move ordering, transposition tables, quiescence and friends — is how a search reaches useful depth without visiting all of them. (Branching factors are approximate published averages, à la Allis 1994, for illustration.)

The same idea, five different games

Every opponent is this algorithm with a different board, a different way of scoring a position, and different tricks to search deeper without searching everything:

Game	Board	Branching (approx.)	Search tricks
Tic-Tac-Toe	3×3	≤ 9 (~4)	Minimax + alpha-beta, full depth on 3×3
Connect 4	7×6	≤ 7 (~4)	Bitboard negamax + alpha-beta + transposition table + iterative deepening
Checkers	8×8	~2.8	Iterative-deepening negamax + alpha-beta + capture quiescence
Othello	8×8	~10	Iterative-deepening negamax + alpha-beta + exact endgame solve
Chess	8×8	~35	Negamax + alpha-beta + null-move + quiescence + check extensions + move ordering

Read the real code

The pseudocode above is the shape. Here's a real, unminified engine that runs one of these opponents in the browser — iterative-deepening negamax with alpha-beta pruning and capture-aware quiescence, about 230 lines of vanilla JS: the checkers engine on GitHub Gist.

Everything runs client-side, zero dependencies. If you'd rather watch the tree animate and prune than read about it, the interactive version is here: Watch a Game AI Think →

What is one ply of search actually worth? I benchmarked 4 game engines

Lucian (LKB) — Wed, 19 Aug 2026 13:32:00 +0000

Syndicated from the original on lkforge.com. The engines are live in your browser at lkforge.com/games; the full harness is in this gist.

My browser board-game opponents — Connect 4, Checkers, Othello and Chess — all think the same way: negamax with alpha-beta pruning, looking a fixed number of moves ahead. The single knob that makes them stronger is search depth. So how much is one more ply actually worth? I ran 2,400 headless self-play games to find out, and the honest answer is: it depends enormously on which ply.

The counterintuitive result

I expected a tidy law — "each ply is worth some steady fraction of the last." I got nothing of the sort.

The very first extra ply is worth a fortune — up to +953 Elo in Connect 4 — because a depth-1 engine barely beats random. After that the gains fall off a cliff and stop behaving: each further ply adds a small, game-specific, non-monotonic amount. There is no single clean curve.

Engine	Depths tested	First ply (1→2)	Each later ply
Connect 4	1–7	+953	+9 to +55
Othello	1–6	+610	+107 to +229
Checkers	1–7	+546	+49 to +100
Chess	1–4	+321	+225 to +315

In 3 of the 4 games, the first ply is the single biggest gain — by a mile.

Why depth, not milliseconds

The live game gives its AI a time budget so the page stays responsive. But a time budget is the wrong unit for a benchmark: "half a second of thinking" buys a fast laptop far more nodes than a phone, so a strength number tied to milliseconds says more about the reader's hardware than the engine.

A fixed search depth is the hardware-independent knob. Pin the depth and the same seed produces the same games on any machine — which is the whole point of publishing a number someone else can check.

Why the first ply does all the work

A depth-1 search only avoids one-move blunders and otherwise plays close to random. The jump to depth 2 turns a coin-flip opponent into a real one — so that ply captures most of the available strength in one step. After that, each additional ply is chasing rarer and rarer mistakes while costing exponentially more nodes, and how much it finds depends entirely on the game.

Chess is the exception that proves the point. Its first two plies are almost equal (+321 then +315) rather than front-loaded, because its branching factor is so large that even a depth-2 search is still missing a great deal — there's plenty left for the next ply to find.

Connect 4 is the opposite extreme: a small, near-solved game where, once past the blunder-avoiding first ply, extra depth barely moves the result (+9 to +55) until the search can see a whole forced line. Its later plies also zig-zag — a real parity effect, because whether the search horizon ends on your move or the opponent's changes what a shallow search sees, so odd and even depths behave differently.

The method

Each engine's shipped search() is deterministic, so every game starts from a random opening (a handful of random legal moves), then the two depth-limited engines play it out.
Every opening is played twice with the sides swapped, so any imbalance in the random start cancels exactly. Draws score half a point.
120 colour-balanced games per adjacent depth pair. Depth — not milliseconds — is the knob, so numbers are hardware-independent and reproduce from a seed (mulberry32, master seed 20260819).
Elo per step = 400 · log10(p / (1 − p)) from the colour-balanced score p.

(Draw rates run high in Checkers and Chess, so read those Elo gaps as approximate. The figures are internal — each engine against weaker copies of itself, not against human ranks or a program like Stockfish.)

The contrast with MCTS

The companion study benchmarks my Go engine, which uses Monte Carlo Tree Search instead of negamax. There, more search bought a smooth, even growing return — each doubling of playouts added more Elo than the last, no diminishing returns out to 1,600 playouts.

Depth-limited negamax has no such curve: it's front-loaded and game-specific. Same goal — pick the strongest move — two search paradigms, two completely different shapes of return on compute. That's the fun of measuring instead of assuming.

Full harness, four vendored engine snapshots, and reproduce steps: gist · original writeup with charts: lkforge.com/blog/search-depth-scaling · the Go/MCTS companion: Does thinking twice as long make a Go AI twice as good? · play the engines: lkforge.com/games.

The World Clock Time-Zone Landscape: what 162 places reveal about time zones

Lucian (LKB) — Sun, 16 Aug 2026 18:21:25 +0000

Time zones look like a tidy grid of whole hours. They aren't. I read the standard UTC offset of all 162 cities, countries and regions on our World Clock straight from the IANA database (via Intl) — and the real shape is lumpy, with quarter-hour outliers and a near-even split over whether clocks move at all.

The quirk, in one line: Kathmandu keeps its clocks 5 hours 45 minutes ahead of UTC — the only :45 offset on the board, and one of 11 places out of 162 that don't sit on a whole hour. Nearly half the rest never move their clocks at all.

The clocks that don't sit on the hour

Most of the world rounds to a whole hour from UTC. A handful don't:

Offset	Places
UTC+3:30	Tehran (Iran)
UTC+4:30	Kabul (Afghanistan)
UTC+5:30	India — New Delhi, Mumbai, Kolkata, Bengaluru, Hyderabad
UTC+5:45	Kathmandu (Nepal)
UTC+9:30	Adelaide, Darwin (Australia)

Half-hour and quarter-hour offsets are a reminder that a time zone is a political decision, not an astronomical one — which is exactly why date code should read the IANA database rather than dividing longitude by 15.

Nearly half never change their clocks

Daylight saving feels universal if you live in North America or Europe, but it isn't. Of the 162 places tracked, 87 (54%) shift their clocks and 75 (46%) never do. The whole of East Asia, the Gulf, most of Africa, India and much of South America keep one fixed offset year-round — Tokyo, Singapore, Dubai, Nairobi and New Delhi never spring forward.

Where the clocks crowd together

Offsets aren't evenly populated. Four of them carry nearly half the board:

Offset	Places	Who's there
UTC−5	25	US Eastern — New York, Toronto, Miami, Boston
UTC+1	21	Central Europe — Paris, Berlin, Rome, Madrid
UTC−6	14	US Central — Chicago, Dallas, Mexico City
UTC+2	12	Eastern Europe & Africa — Athens, Cairo, Johannesburg

The full set spans 22 hours, from Honolulu at UTC−10 to New Zealand and Fiji at UTC+12.

Reproduce it

Every number here is printed by one dependency-free Node script that reads each place's standard offset from the IANA database via Intl for January and July 2025 (a place "observes DST" when the two differ):

→ Run it yourself (public gist)

All figures are scoped to the 162 places the clock tracks, not every zone on Earth (globally there are other quarter-hour oddities, like the Chatham Islands at +12:45).

Originally published at lkforge.com, where the offset distribution is an interactive chart. Built alongside the free LK Forge World Clock.

Is Friday the 13th really more common? I counted 400 years to find out

Lucian (LKB) — Sun, 16 Aug 2026 18:20:40 +0000

The superstition claims Friday the 13th is unlucky. It turns out it's also, very slightly, the most likely — the 13th lands on a Friday more often than on any other weekday. I counted every month in a full 400-year Gregorian cycle (plain Date UTC math) to see how big that edge really is.

The edge, in one line: over 400 years the 13th falls on a Friday 688 times — more than any other weekday — but the rarest weekday still gets 684. The superstition has a real statistical edge; it's just a minuscule one.

Which weekday the 13th prefers

Counts across all 4,800 months of one cycle. The mean, if it were perfectly even, would be 685.7:

Weekday	Times the 13th lands here
Friday	688
Sunday	687
Wednesday	687
Monday	685
Tuesday	685
Thursday	684
Saturday	684

Friday wins — by about two months in 4,800. On a true zero-based axis the seven bars are almost identical, and that is the story: the bias is real but tiny, an artefact of how the Gregorian leap rule favours some starting weekdays over others.

You can't dodge it: every year has one

However the weekdays fall, no year escapes a Friday the 13th — and no year has more than three. Across the cycle, 171 years have exactly one, 170 have two, and 59 have three.

(For the record: the next Friday the 13ths are Nov 13 2026, Aug 13 2027, and Oct 13 2028.)

The calendar is a 400-year loop

Here's the fact that makes every count above exact rather than an estimate. A 400-year block holds 97 leap years and 146,097 days — and 146,097 divides by seven with nothing left over, giving exactly 20,871 weeks. Because days and weeks line up perfectly at the 400-year mark, the entire calendar resets and repeats. Your birthday in 2426 falls on the same weekday it does in 2026.

And some years get 53 weeks

Most years span 52 ISO weeks, but 71 of every 400 (about 17.8%) carry 53 — a year does when it starts on a Thursday, or on a Wednesday in a leap year. The next 53-week years are 2026, 2032, 2037 and 2043. That extra week is why payroll and planning calendars occasionally gain a period.

Reproduce it

Every number is printed by one dependency-free Node script over one 400-year cycle (the calendar repeats, so the counts are exact, not sampled):

→ Run it yourself (public gist)

Originally published at lkforge.com, where the weekday distribution is an interactive deviation chart. Built alongside the free LK Forge Calendar tools.

US sales tax by state: California 7.25%, five states at 0%, average 5.11%

Lucian (LKB) — Fri, 07 Aug 2026 22:00:57 +0000

While building a sales-tax calculator I needed the statewide base rate for every US state. Once the table was in code, ranking it took three lines — and the result is a cleaner picture than most "sales tax by state" posts, because it keeps one distinction straight: these are state base rates, not the combined rate at the register.

The data

Statewide base rate (%), 50 states + DC — the exact table the calculator ships:

// abbreviated; full 51-row table in the post
const rates = [
  7.25, 7, 7, 7, 7, 6.88, 6.85, 6.63, 6.5, 6.5, 6.5, 6.35,
  6.25, 6.25, 6.25, 6.1, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
  5.75, 5.6, 5.5, 5.5, 5.3, 5, 5, 5, 4.88, 4.75, 4.5, 4.23,
  4.2, 4, 4, 4, 4, 4, 2.9, 0, 0, 0, 0, 0,
];

The findings — all just arithmetic

const avg = rates.reduce((a, b) => a + b, 0) / rates.length;
const sorted = [...rates].sort((a, b) => a - b);
const median = sorted[Math.floor(sorted.length / 2)];

console.log(rates.length);              // 51
console.log(avg.toFixed(2));            // 5.11
console.log(median);                    // 6
console.log(rates.filter(r => r === 0).length); // 5

California is highest at 7.25%. Four states follow at 7% (Indiana, Mississippi, Rhode Island, Tennessee).
Five states charge no statewide sales tax — the NOMAD set: New Hampshire, Oregon, Montana, Alaska, Delaware.
Average 5.11%, median 6%. Most states cluster right at 6%.
On a $1,000 purchase that's a $72.50 swing between the top state and the no-tax five — before any local tax.

The catch everyone blurs

These are base state rates. Many cities and counties add their own sales tax on top, so the combined rate at checkout is higher — in places like Tennessee and Louisiana, higher than California's. And Alaska has no state sales tax but permits local ones, so "0%" isn't 0% everywhere in Alaska. A ranking that mixes base and combined rates quietly compares apples to oranges; this one doesn't.

Full ranked table (all 51, with tax-on-$1,000) + chart: US Sales Tax by State →

Every figure is arithmetic on that one rate table — reproducible with the snippet above.

A cup is not a cup: 9 baking staples, one volume, a 2.66x weight spread

Lucian (LKB) — Fri, 07 Aug 2026 21:58:14 +0000

A recipe says "1 cup of flour." My kitchen scale and yours will disagree about what that weighs — because a cup measures volume, and ingredients don't share a density.

I was building a cooking-unit converter and had to bake in real grams-per-cup densities. The moment they were sitting in one table, the spread jumped out.

The data

Grams per US cup — the King Arthur Ingredient Weight Chart the converter ships (water is defined by volume, 1 cup = 236.588 mL ≈ 236.588 g):

const gramsPerCup = {
  'Water':             236.588,
  'Butter':            227,
  'Milk':              227,
  'Brown sugar':       213,   // packed
  'Granulated sugar':  198,
  'Rice (dry)':        198,
  'All-purpose flour': 120,
  'Powdered sugar':    113,
  'Oats':              89,
};

The findings — all just arithmetic

const vals = Object.values(gramsPerCup);

const spread = Math.max(...vals) / Math.min(...vals);
console.log(spread.toFixed(2));                 // 2.66  (water 237 g vs oats 89 g)

console.log((198 / 120 - 1) * 100);             // 65  — sugar vs flour
console.log(((198 / 113 - 1) * 100).toFixed(0)); // 75  — granulated vs powdered sugar

2.66× between the heaviest cup (water, ~237 g) and the lightest (oats, 89 g).
A cup of granulated sugar is ~65% heavier than a cup of flour — identical volume.
Granulated vs powdered sugar: ~75% apart, and both are just labelled "sugar."

So "1 cup" can mean anywhere from 89 g to 237 g depending on what's in it. And that's before human error: scoop flour straight from the bag and you pack it — a "cup" can hit 150 g+, a 25% overshoot before you've done anything wrong.

Why this matters for code, not just baking

Any app that converts recipe units has to carry per-ingredient density or it's silently wrong. Volume→weight isn't one constant; it's a lookup table. (16 tbsp = 1 cup, so grams-per-tablespoon is just grams-per-cup ÷ 16 — no separate data needed.)

Full ranked table + chart: A Cup Is Not a Cup →

Every gram figure is the King Arthur chart the converter ships, and each claim above is reproducible with the snippet.

The BMI-to-body-fat gap is a constant 22.3 points at every BMI

Lucian (LKB) — Fri, 07 Aug 2026 21:40:39 +0000

BMI is one number: your weight divided by the square of your height. It has no term for age, no term for sex, no term for how much of your weight is muscle. So I got curious about a simple question while building a body-fat calculator:

If two people have the exact same BMI, how different can their body fat actually be?

The answer turned out cleaner than I expected — and it's a nice little demonstration of how a linear formula hides variance in plain sight.

The formula

The standard way to turn a BMI into a body-fat estimate is the Deurenberg equation. It's the "BMI method" our Body Fat Calculator ships:

const bodyFat = (bmi, age, isMale) =>
  1.20 * bmi + 0.23 * age - 10.8 * (isMale ? 1 : 0) - 5.4;

Four terms. Only the first one involves BMI at all.

Four people, one BMI of 25

BMI 25 is the line where "normal" becomes "overweight." Let's put four people right on it and run the formula:

for (const [who, age, male] of [
  ['Man, 20',   20, true],
  ['Woman, 20', 20, false],
  ['Man, 70',   70, true],
  ['Woman, 70', 70, false],
]) {
  console.log(who.padEnd(10), bodyFat(25, age, male).toFixed(1) + '%');
}
// Man, 20    18.4%
// Woman, 20  29.2%
// Man, 70    29.9%
// Woman, 70  40.7%

Same BMI. Same "overweight" label. Body fat from 18.4% to 40.7% — a 22.3-point spread. Run those through the ACE body-fat categories and two of them come out "Average" and two come out "Obese." One number, opposite verdicts.

The part I didn't expect: the gap never changes

Here's the neat bit. Because the sex term (-10.8) and the age term (0.23 * age) are added on independent of BMI, the distance between the leanest archetype (a 20-year-old man) and the highest (a 70-year-old woman) is a fixed amount at every BMI:

const low  = (bmi) => bodyFat(bmi, 20, true);   // leanest read
const high = (bmi) => bodyFat(bmi, 70, false);  // highest read

const gaps = new Set();
for (let bmi = 18.5; bmi <= 35; bmi += 0.5) {
  gaps.add(+(high(bmi) - low(bmi)).toFixed(1));
}
console.log([...gaps]); // [ 22.3 ]

One distinct value: 22.3. The two body-fat-vs-BMI lines are perfectly parallel — a 22.3-point ribbon that just slides upward as BMI climbs. Decomposed:

Sex: a woman reads exactly 10.8 points higher than a man at the same BMI and age. It's a literal constant in the equation.
Age: 0.23 points per year, so 20 → 70 adds 11.5 points.
10.8 + 11.5 = 22.3, forever.

So BMI can tell you where you land on the weight-for-height scale. It structurally cannot tell you which end of that 22.3-point band you're in — that information isn't in the inputs.

The honest caveat

The Deurenberg estimate is a rough BMI-based approximation, not a clinical measurement — the point here is how much a single BMI can hide, not a precise personal number. If you actually want a body-fat estimate, a tape-measure method (like the U.S. Navy girth formula) uses real body measurements and is meaningfully better. Both are in the calculator.

Full write-up with the chart and the category math: Same BMI, Different Body Fat →

Every number above is arithmetic on that one formula — copy the snippets and you'll get the same figures.

OCR and sign a PDF entirely in the browser — no upload, no server

Lucian (LKB) — Fri, 07 Aug 2026 16:55:18 +0000

Most "free online PDF" tools quietly upload your document to a server. For a signed contract or a scanned ID, that's the whole problem. So I built two tools that don't: an OCR PDF that turns a scanned PDF into a searchable one, and a Sign PDF that adds your signature — both running 100% in the browser. Nothing is uploaded; close the tab and it's gone.

Here's how each one works, plus the part that actually took the effort: getting WebAssembly OCR to run under a strict Content-Security-Policy with no CDN.

OCR: scanned PDF → searchable PDF, client-side

A scanned PDF is just images. You can't select or search the text. "OCR" means recognizing the characters and — for a searchable PDF — laying an invisible text layer over the page image so the document looks identical but the words are now selectable.

The pipeline, entirely in the tab:

Render each page to a canvas with pdf.js.
Recognize the text with tesseract.js (WebAssembly OCR).
Rebuild a new PDF with pdf-lib: draw the page image, then stamp each recognized word as invisible text at its bounding box.

The recognizer is a vendored worker — no CDN, English fast model:

const worker = await Tesseract.createWorker('eng', 1, {
  workerPath: VENDOR + '/worker.min.js',
  corePath:   VENDOR + '/tesseract-core-simd-lstm.wasm.js',
  langPath:   VENDOR,            // holds eng.traineddata.gz
  workerBlobURL: false,
  logger: m => { if (m.status === 'recognizing text')
    setProgress(m.progress); },
});

The interesting bit is the invisible text layer. tesseract gives you words with bounding boxes in canvas pixels; pdf-lib draws text in PDF points with the origin bottom-left. So for each word you map the box, size the font to the box height, and draw it with opacity: 0:

const page = out.addPage([Wpt, Hpt]);
page.drawImage(jpg, { x: 0, y: 0, width: Wpt, height: Hpt }); // the scan
const k = Wpt / canvas.width;                                 // px → pt

for (const w of words) {
  const size = Math.max(4, (w.y1 - w.y0) * k * 0.9);
  page.drawText(sanitize(w.text), {
    x: w.x0 * k,
    y: Hpt - w.y1 * k + size * 0.15,   // flip Y, sit on the baseline
    size, font, opacity: 0,            // invisible, but selectable
  });
}

The result looks exactly like the scan, but you can select, copy, and Ctrl-F the text — and I also dump the plain text into a box you can copy or download as .txt.

Honest limits (all stated on the page too): it uses the English model, alignment is word-level (great for search, not a character-perfect copy), and accuracy tracks scan quality — clean, straight, high-contrast pages read best. A quick sanity check: feed it an image of OCR Verification Test 2026 and the output PDF's text layer comes back as exactly that.

The hard part: WASM under a strict CSP, no CDN

The site runs a locked-down CSP — default-src 'self', connect-src 'self', no unsafe-eval. That breaks the usual tesseract.js setup twice over:

No CDN. The worker, the WASM core, and the language data all have to be same-origin. So I vendor them (tesseract.min.js, worker.min.js, tesseract-core-simd-lstm.wasm(.js), and a gzipped eng.traineddata.gz — ~8.8 MB total, served from my own origin).
WASM needs wasm-unsafe-eval. But I don't want that on the whole site — just the one route. The CSP is built per-request in a Cloudflare Worker, so I scope a flag to the OCR path (and, crucially, its vendored assets, because the Web Worker inherits its CSP from its own script response):

const ocr = url.pathname.startsWith('/tools/pdf/ocr-pdf'); // page + /vendor/*
// in buildCsp():
`script-src 'self' 'nonce-${nonce}'${ocr ? " 'wasm-unsafe-eval'" : ''}`,
ocr && "worker-src 'self' blob:",

Everything else on the site stays wasm-unsafe-eval-free.

The gotcha that cost me an hour: tesseract resolves workerPath/corePath against its own script's location, not the page. A relative ./vendor/... fails with a silent, empty-message "unknown error." The fix is an absolute same-origin URL:

const VENDOR = window.location.origin + '/tools/pdf/ocr-pdf/vendor';

(If you've self-hosted ffmpeg.wasm before, this will feel familiar — same lesson.)

Sign: draw, type, or upload — then flatten it in

The signature tool is simpler but the same philosophy. You make a signature three ways:

Draw on a canvas with pointer events.
Type your name in a script font (ctx.fillText with a cursive stack).
Upload an image (a transparent PNG looks best).

Whichever you pick, I trim the transparent margins, turn it into a PNG, let you drag/resize it onto a page preview (rendered by pdf.js), then stamp it in with pdf-lib — mapping the on-screen box to page coordinates the same way the OCR layer does:

const png = await doc.embedPng(signatureBytes);
const pg  = doc.getPages()[pageIndex];
pg.drawImage(png, {
  x: fx * W,
  y: H - (fy + fh) * H,   // top-left screen box → bottom-left PDF
  width: fw * W,
  height: fh * H,
});

Honest framing (also on the page): this adds a visible signature image — like signing a printout and scanning it. It is not a certificate-based cryptographic e-signature with a verified identity. For most "just sign this and send it back" jobs, that's exactly what you want; for anything that needs legal non-repudiation, use a dedicated e-sign service.

Why do it all client-side?

Three reasons, in order:

Privacy. The file never leaves the tab. There's no upload to log, cache, or breach — a real difference for signed documents and scanned IDs.
No infrastructure. No servers, no queues, no per-file cost. The browser does the work; I just ship static assets and a thin Worker for headers.
It's free and account-free, because it's cheap to run when the user's device is the compute.

The trade-off is honest: OCR is slower than a beefy server (it's your CPU + WASM), and there's an ~8.8 MB one-time download for the model. For a privacy-first tool, I'll take that.

Both tools are live and free — no signup, no watermark, nothing uploaded:

OCR PDF → https://lkforge.com/tools/pdf/ocr-pdf/
Sign PDF → https://lkforge.com/tools/pdf/sign-pdf/

They're part of a 24-tool browser-only PDF suite (crop, merge, compress, watermark, page numbers, HTML→PDF, and more) — all built on the same "nothing leaves your device" rule.

If you've fought tesseract.js under a strict CSP, I'd love to hear how you scoped it.

I tried to beat my own Tic-Tac-Toe AI 1,270 ways. It never lost.

Lucian (LKB) — Fri, 07 Aug 2026 05:30:40 +0000

Everyone says a minimax Tic-Tac-Toe bot is "unbeatable." I wanted a number, not a vibe — so I benchmarked the exact engine that ships on my game. The code is open source; every figure below reproduces with node benchmark.js, and there's a full writeup with charts.

1. The proof isn't a sample — it's the whole game tree

On 3×3, Hard mode's reply is deterministic (full depth-9 minimax + alpha-beta), so you can enumerate every reachable game. Playing second, as it does in the game: 569 lines → 386 wins, 183 draws, 0 losses. Playing first: 73 lines → 71 wins, 2 draws, 0 losses. Across all 642 lines it never loses. On 3×3, "unbeatable" is literally the game tree, not a claim.

2. Alpha-beta earns its keep

Choosing the opening move at full depth, plain minimax visits 549,945 positions; alpha-beta cuts that to 36,528 — a 93.4% reduction for an identical answer.

3. Does it break on bigger boards?

The engine caps its search depth as boards grow (9 → 7 → 5 → 3). I expected that to open a crack. It didn't: across 628 simulated games up to 6×6, against random and greedy opponents, still 0 losses. What changes isn't losing — it's that forcing a win gets harder, so results drift toward draws (3×3 91.8% win, 4×4 72.5%, 5×5 96.7%, 6×6 100% vs random).

Why it holds up: it always blocks an immediate threat before searching, and 4-in-a-row stays defensible within the depth cap. The interesting fragility is theoretical — a human who can plant a fork beyond the AI's horizon — which is exactly why the full game offers 4×4 up to 10×10.

Engine + benchmark: https://github.com/lucian-devops/tictactoe-ai. Play it: https://lkforge.com/games/tictactoe/. Full writeup: https://lkforge.com/games/tictactoe/blog-how-the-ai-works/.

Three Sudoku solvers, one engine, 34,000 fewer guesses

Lucian (LKB) — Thu, 06 Aug 2026 19:01:00 +0000

The Sudoku generator that ships in my puzzle game is a plain randomised-backtracking solver. It works, but "it works" is a vibe, not a number. So I pointed three different solving strategies at the exact same engine and counted how hard each one actually has to search.

The engine and the benchmark are open source. Every node count below is deterministic — clone it, run node benchmark.js, and you get the same figures I did.

The setup

A grid is a flat array of 81 cells (0 = empty). The corpus is 40 puzzles — 10 each of Easy, Medium, Hard and Expert — generated by the shipped generator with fixed seeds, so the exact same 40 puzzles rebuild every run.

The metric I care about is search nodes: how many cells the solver has to guess at and recurse on. Wall-clock time depends on your laptop; node counts don't. (Times below are from my machine, rounded, for flavour only.)

Three strategies, all solving the identical puzzles:

Naive backtracking — the algorithm the game actually ships. Fill the next empty cell, try 1–9, recurse, undo on failure.
MRV backtracking — same idea, but always branch on the cell with the fewest candidates first (a most-constrained-variable heuristic).
Logic (constraint propagation) — before ever guessing, repeatedly apply naked singles and hidden singles to deduce forced cells. This is the same kind of reasoning the game's AI-hint button explains, only run to exhaustion.

Before comparing anything, the harness asserts all three return the same solution on all 40 puzzles. Mismatches: 0. So we're comparing correct solvers, not fast-but-wrong ones.

The numbers

Average search nodes per puzzle (node benchmark.js, 10 puzzles/tier, seeded):

difficulty	naive backtracking	MRV backtracking	logic (propagation)
Easy	59	37	1
Medium	598	55	1
Hard	10,750	380	2
Expert	103,932	238	3
all 40	28,835	177	2

A few things jump out:

Naive backtracking falls off a cliff on Expert — ~104k search nodes on average (~9 ms), versus 59 on Easy. Fewer clues means longer, blinder guessing chains.
MRV flattens that cliff. Overall it explores ~163× fewer nodes than naive (28,835 → 177). Just always branching on the most-constrained cell keeps the whole search cheap.
Logic barely searches at all. Easy and Medium puzzles solve in a single node — zero guessing, pure deduction. Even Expert takes ~3. Overall that's 28,835 → 2, roughly 14,000× fewer search nodes than naive, and on Expert alone, 103,932 → 3 — about 34,000×.

One honest quirk: for MRV, Expert (238) actually edges out Hard (380). With only ~24 clues, Expert grids give constraint propagation more to bite on, and with 10 puzzles per tier there's real sample variance. I'm leaving it in rather than cherry-picking a monotonic table.

Why the gap is so big

Naive backtracking treats every empty cell as equally worth guessing, so on a sparse grid it wanders down enormous doomed branches before backing out. MRV never guesses on a cell with five options when one with two is available — most of the tree simply never gets built. And logic solving asks a different question entirely: not "which value do I try here?" but "which cell is already forced?" On anything up to Hard, that question has an answer often enough that you never have to guess.

That last point is also why the game feels fair: the same singles the propagation solver uses to avoid guessing are the moves the hint engine points at, so every puzzle is solvable by reasoning, not luck.

Reproduce it

git clone https://github.com/lucian-devops/sudoku-solver
cd sudoku-solver
node benchmark.js        # the table above (deterministic node counts)
node benchmark.js 50     # 50 puzzles/tier if you want steadier averages

engine.js is the actual generator/solver from the live game, extracted verbatim; the instrumented solver variants (node counters, MRV, propagation) live in benchmark.js so the shipped module stays exactly what players get.

If you want to see the shipped solver working on a real board, there's a full write-up with the same numbers here: How a Sudoku solver works → — or just play a puzzle and hit the hint button to watch the propagation logic name each move.

Numbers computed from the real shipped engine, not a reimplementation. Corpus and counts are seeded and reproducible.

How an AI actually beats 2048 (expectimax, not an LLM)

Lucian (LKB) — Mon, 03 Aug 2026 11:54:45 +0000

Every number in this post comes from our own re-runnable 250-game self-play benchmark. Nothing here is estimated.

If you've ever asked "are there any AI tools that can actually beat 2048?", the answer is yes — and the interesting part is which kind of AI does it. It is not a language model. A 2048-solving AI is a small, deterministic search algorithm you can run in a browser tab with no network calls. Here is exactly how one works, and where it hits its ceiling.

Why not an LLM?

You could paste the board into a chat model and ask for a move. It will often give you a plausible one — and sometimes an illegal or losing one — because a language model predicts the next tokens of text, not the next move of a game tree. Winning a game of chance is a search problem, and we already have an exact algorithm for it.

	Game-tree search	A language model
How a move is chosen	Search the tree, return a specific legal move	Predict tokens; the "move" is whatever it writes
Determinism	Same board → same move, every time	Sampling is probabilistic
Latency	Sub-millisecond, on your device	An API round-trip
Cost / offline	Free, offline, no key	Hosted or paid API

The core idea: expectimax

2048 is a game against chance — you pick a direction, then the game drops a random tile (a 2 with 90% probability, a 4 with 10%) on a random empty square. The right tool is expectimax search, a tree that alternates two layer types:

On a max layer the AI tries all four moves and keeps the best.
On a chance layer it considers every square a new tile could land on and averages the outcomes, weighted by probability.

By looking several layers deep, it picks the move whose likely future is strongest — accounting for unlucky spawns instead of grabbing whatever looks good right now.

Why not minimax? Minimax assumes an adversary playing the worst tile against you. But 2048's tiles are random, not malicious. Averaging over outcomes (expectimax) models the real game; minimax would play far too defensively. This is the textbook split — minimax for chess, expectimax for games against nature.

The heuristic: scoring a board

Search needs a way to score a board it can't play all the way out. The whole evaluation is three terms:

score = positional + empties × 200000 + smoothness × 4000

Positional (corner-snake) — each square has a fixed rank; a tile's value is multiplied by 4^rank. Because the weights grow as powers of four, one big tile in the corner dominates everything, so the search is rewarded for stacking value toward that corner in snake order.
Empty squares — every blank cell is worth a flat 200000. Empty space is what keeps future moves legal, so a nearly-full board scores as almost worthless no matter how large its tiles.
Smoothness — for each pair of neighbours, subtract |log2(a) − log2(b)|. Mergeable neighbours cost almost nothing; a 2 next to a 512 is punished. Jagged boards score lower.

How well does it actually play?

We ran the exact search code headless for 250 full games:

Who / what	Top tile	Notes
Theoretical maximum	131,072	Absolute ceiling on a 4×4 board
Best research AI (2025)	65,536	Reached ~8.4% of games; median score ~820,000
This browser solver	4,096	~30% of games; reaches 2048 ~70% of the time
Most human players	2,048	The original win condition

So a simple expectimax solver clears the 2048 win condition in about 70% of games and pushes to 4096 in about 30% — and essentially never reaches 8192. The state-of-the-art research AIs (expectiminimax plus endgame tablebases) go two doublings higher, to 65,536, but even they hit that only ~8% of the time. The theoretical 131,072 ceiling is never reached in normal play.

Try it / reproduce it

You can watch this exact solver run by turning on Autoplay in the free browser game at lkforge.com/games/2048 — no install, no account, runs entirely on your device. The full heuristic breakdown and the benchmark methodology are in the original write-up.

The engine is also open source (MIT) if you want to read it, require() it, or run the benchmark yourself: github.com/lucian-devops/2048-ai-solver — and there's a live self-play demo that watches the AI play.

If you want to build your own: implement expectimax with a depth of 3–5, use the three-term heuristic above, and run a few hundred self-play games to measure your own reach rates. The whole thing fits in a couple hundred lines of JavaScript.