DEV Community: farcrak

My number input turned 3,635,758 into 758 and said nothing

farcrak — Tue, 18 Aug 2026 14:18:46 +0000

I run a small site with a few hundred calculators. One of them writes an amount out in words — the thing you have to do on a cheque or a contract in Spanish. It is by a wide margin my most successful page: it brings 43 of the 44 search clicks the whole site gets in a month.

Yesterday I finally looked at which searches those were. Almost all of them were shaped like this:

como se escribe con letra 1,370,801,919.12
3.635.758 escribir letras
10,377.84 se escribe en letra
como se escribe 77107,10 enletra

People do not arrive wondering how the tool works. They arrive with a number already in their hand, copied out of an invoice, and they paste it.

So I pasted one myself.

3.635.758 went into the field. The field showed 758. And the page answered, in complete confidence:

setecientos cincuenta y ocho euros

Seven hundred fifty-eight euros. The number was three million six hundred thirty-five thousand seven hundred fifty-eight. Off by a factor of about 4,800, with no error, no warning, nothing red. On a page whose entire job is to produce the amount you then sign your name under.

Why it happens

The field was <input type="number">.

That input does not accept "a number as people write it". Per the HTML spec it accepts a valid floating-point number: optional sign, digits, optional . and more digits, optional exponent. That's it. No thousands separators. No locale. 1,234.56 is not a valid value. Neither is 1.234.567,89. Neither is 1 234,56.

What the browser does with an invalid value is the actual problem. It doesn't reject the input in a way you notice. Typing character by character, each keystroke is sanitized against that grammar, and you are left with whatever survived — in my case, 758. Pasting usually leaves you with an empty string instead, and element.value is "". valueAsNumber hands you NaN.

Every one of those outcomes is silent. The field looks fine. And that is the part worth internalising: type="number" doesn't protect you from bad input, it converts bad input into plausible input. A blank field is a bug you notice. 758 is a bug that ships.

The same bug from the other end

While I was in there I found the server-side half:

const normalized = value.replace(",", ".").trim();
const numeric = Number(normalized);
return Number.isFinite(numeric) ? numeric : fallback;

String.prototype.replace with a string pattern replaces the first match only. I wrote that line myself and had read past it many times.

"1234,56" becomes "1234.56" becomes 1234.56. Fine — which is why it survived so long.
"1 234,56" becomes "1 234.56" becomes NaN, and falls back to 0.
"1,234.56" becomes "1.234.56" becomes NaN, and falls back to 0.

So the two halves of the same system failed in opposite directions — one invented a small number, the other invented zero — and both did it quietly.

Reading a number the way a person reads it

You cannot fix this by picking one locale. My own traffic proves it: 10,377.84 and 77107,10 are both real inputs from real people on the same page, one written the American way and one the Spanish way. Force either convention and you are wrong for half your users.

But you don't need to guess, because a human reading 1.370.801.919,12 has no trouble at all. Write down what they're doing:

Both . and , appear — the one that appears last is the decimal separator, the other groups thousands. 1,370,801,919.12 decides on .; 208.333.333,33 decides on ,.
One kind of separator, and it repeats — it groups thousands. 3.635.758 has two dots, so the dots are grouping.
One separator, exactly three digits after it — genuinely ambiguous. 1.234 is "one thousand two hundred thirty-four" to a Spaniard and "one point two three four" to an American, and nothing in the string tells you which. This is the only case where the page's own locale decides.
Anything else — decimal separator. 77107,10, 1.5, 0,5.

Here it is, minus the currency-symbol stripping:

export function parseHumanNumber(raw, decimalSeparator) {
  const cleaned = raw.replace(/[\s  ]/g, "").replace(/[€$£¥]/g, "");
  if (!cleaned) return null;

  const negative = cleaned.startsWith("-");
  const body = cleaned.replace(/^[+-]/, "");
  if (!/^[\d.,]+$/.test(body)) return null;

  const lastDot = body.lastIndexOf(".");
  const lastComma = body.lastIndexOf(",");
  let decimalAt = -1;

  if (lastDot >= 0 && lastComma >= 0) {
    decimalAt = Math.max(lastDot, lastComma);          // rule 1
  } else if (lastDot >= 0 || lastComma >= 0) {
    const at = Math.max(lastDot, lastComma);
    const mark = body[at];
    const howMany = body.split(mark).length - 1;
    const digitsAfter = body.length - at - 1;

    if (howMany > 1) decimalAt = -1;                   // rule 2
    else if (digitsAfter === 3)                        // rule 3
      decimalAt = mark === decimalSeparator ? at : -1;
    else decimalAt = at;                               // rule 4
  }

  const wholeRaw = decimalAt >= 0 ? body.slice(0, decimalAt) : body;
  const fraction = decimalAt >= 0 ? body.slice(decimalAt + 1) : "";
  if (/[.,]/.test(fraction)) return null;

  // Separators left in the integer part have to be real grouping:
  // one kind of mark, groups of exactly three.
  if (/[.,]/.test(wholeRaw)) {
    if (wholeRaw.includes(".") && wholeRaw.includes(",")) return null;
    const mark = wholeRaw.includes(".") ? "." : ",";
    const groups = wholeRaw.split(mark);
    if (groups[0].length < 1 || groups[0].length > 3) return null;
    if (groups.slice(1).some((g) => g.length !== 3)) return null;
  }

  const whole = wholeRaw.replace(/[.,]/g, "");
  if (!whole && !fraction) return null;

  const value = Number(`${whole || "0"}.${fraction || "0"}`);
  return Number.isFinite(value) ? (negative ? -value : value) : null;
}

That last block is the one I nearly skipped, and it matters most. Without it, 1,23,4.5 parses to 1234.5 — a confident answer to a string that means nothing. Returning null on garbage is the whole point. If you are replacing a silent wrong number, do not replace it with a different silent wrong number.

The element itself

<input
  type="text"
  inputMode="decimal"
  value={typed}
  onChange={(e) => {
    setTyped(e.target.value);
    setValue(parseHumanNumber(e.target.value, ",") ?? NaN);
  }}
/>

inputMode="decimal" still brings up the numeric keypad on phones, which is the one thing type="number" was genuinely providing here. You also lose the spinner arrows, and nobody has ever wanted to increment an invoice total by one.

There is a React trap in those few lines. The typed text and the parsed number have to be separate state. If the input's value is the parsed number, then the moment someone types 1, the value is 1, React re-renders, and the comma disappears from under their fingers. They cannot type a decimal at all. Show what they typed; compute from what you understood.

One more change, and it costs nothing

The page now prints the amount it understood, in digits, right beside the words:

1.370.801.919,12 €  ->  mil trescientos setenta millones ochocientos
                        un mil novecientos diecinueve euros con doce céntimos

Any parser like this has a genuinely ambiguous case — rule 3 above. I can pick a sensible default, but I cannot be right every time, and a tool that writes the sum on a contract has no business being quietly wrong. Echoing the parsed number back turns an invisible failure into one the reader catches in half a second.

The tests are just the search log

I didn't invent test cases. I pasted in the actual queries people had used to reach the page:

assert.equal(parse("1,370,801,919.12", ","), 1370801919.12);
assert.equal(parse("3.635.758",        ","), 3635758);
assert.equal(parse("10,377.84",        ","), 10377.84);
assert.equal(parse("77107,10",         ","), 77107.1);
assert.equal(parse("208.333.333,33",   ","), 208333333.33);
assert.equal(parse("$14.688.000",      ","), 14688000);
assert.equal(parse("1 234,56",         ","), 1234.56);

// ambiguity resolved by the page's language
assert.equal(parse("1.234", ","), 1234);   // Spanish page
assert.equal(parse("1.234", "."), 1.234);  // English page

// and the ones that must not produce an answer
for (const junk of ["", "abc", "12abc", "1.2.3,4,5", "1,23,4.5"])
  assert.equal(parse(junk, ","), null);

Your search console already knows the exact strings your users bring you. It is the best fixture list you will ever get, and it is free.

The takeaway

type="number" is fine for a quantity picker. It is the wrong control for any figure a person copies from somewhere else — an invoice total, a salary, a price, an account balance — because those arrive already formatted, and formatting is precisely what that element cannot survive.

Go and paste 1,234.56 into your own form right now. Then paste 1.234,56. Then look at what your backend stored.

The tool in question, if you want to see the fix in place: Número a letras — it writes amounts out in Spanish for contracts and cheques, in euros, pesos or dollars.

How long to cook 200 foods in the oven — as an open dataset with official sources (CC BY-SA 4.0)

farcrak — Thu, 06 Aug 2026 01:08:09 +0000

Yesterday I released a recipe dataset. Today its companion: oven cooking times and temperatures for 200 products, from chicken breast to cheesecake — every number backed by a primary source.

Download

JSON (~216 KB): https://theunitools.com/data/unitools-cooking-times-v1.json
CSV (one product per row): https://theunitools.com/data/unitools-cooking-times-v1.csv
Docs: https://github.com/farcrak/unitools-recipes
Dataset page: https://theunitools.com/en/data

What each record holds

Oven temperature (°C and °F) and a practical time range in minutes
Safe minimum internal temperature where an official one exists (FoodSafety.gov / USDA FSIS charts)
Rest time, reference weight/thickness, doneness levels, and the key geometry driver (thickness vs weight vs batch size)
sources — the actual URLs each number came from: government charts, King Arthur Baking, manufacturer package directions (Ore-Ida, Gorton's, Stouffer's, Totino's…)
confidence — an honest high / medium flag: chart-backed numbers vs converging culinary sources

Why sources per row matter

Most cooking-time tables on the internet are copies of copies with no provenance. Here you can trace "boneless chicken thighs: 18–25 min at 425°F" back to the page it came from, and decide for yourself whether to trust it. The medium confidence flag marks numbers where no official chart exists — that honesty is baked into the data rather than hidden.

Licence

CC BY-SA 4.0 — commercial use allowed. Credit "UniTools — theunitools.com", share derivatives alike.

If you build a kitchen timer, an Alexa skill, or a meal-prep planner on top of it — tell me in the comments, I'd genuinely love to see it.

501 world recipes as an open dataset: per-serving nutrition, step timings, ingredient scaling rules (CC BY-SA 4.0)

farcrak — Thu, 06 Aug 2026 00:05:32 +0000

Last month I wrote about building a 1,800-page calculator site solo. Since then the recipe hub on that site grew to 501 dishes from 127 countries — and today I'm releasing all of it as an open dataset.

Download

JSON (full dataset, ~2.6 MB): https://theunitools.com/data/unitools-recipes-v1.json
CSV (one dish per row): https://theunitools.com/data/unitools-recipes-v1.csv
Docs + sample record: https://github.com/farcrak/unitools-recipes
Dataset page: https://theunitools.com/en/data

What's inside

501 home-cooking recipes, 127 countries, bilingual (English + Russian, both written by hand — no machine translation)
Per-serving nutrition (calories, protein, fat, carbs) on every single dish
3,200+ steps, each annotated with minutes
Ingredients with stable ids and scaling rules: meat scales linearly with servings, salt and spices are damped — the way an actual kitchen scales a recipe, not naive multiplication
Human-reviewed Wikimedia Commons photos with author + licence per photo

Why the scaling rules matter

Most recipe datasets store "2 tbsp salt for 4 servings" and leave scaling to you. Multiply salt linearly to 16 servings and the dish is inedible. Each ingredient in this dataset carries a scaling field (linear | damped | fixed), so a portion calculator can be built directly on top of the data. That's exactly how the recipe pages on the site work.

Licence

CC BY-SA 4.0 — free for commercial use. Credit "UniTools — theunitools.com" and share derivatives under the same licence. Photos carry their own Commons licences (in the data).

Honest caveats

Nutrition is computed from ingredients, not lab-measured — a planning reference, not medical data. The dataset is maintained by one person; if you spot an error, open an issue on the repo and the fix lands in the next version.

If you build something with it — a meal planner, a viz, a model fine-tune — I'd genuinely love to hear about it in the comments.

How I built ~1,800 "honest" calculator pages with Next.js + SQLite

farcrak — Tue, 07 Jul 2026 00:57:08 +0000

It started with a dumb frustration. Every "how long to cook chicken thighs" page gives you a different number, and none of them tell you where the number comes from. Some say 25 minutes, some say 40, and you're standing there with a thermometer wondering who to trust.

So I did the developer thing and over-engineered a solution. What began as one cooking-time calculator turned into ~1,800 generated pages. Here's how it's built and a couple of footguns that cost me real traffic.

The data model: start from a source, not from blog numbers

The core idea: don't hardcode "chicken = 30 min". Start from the official safe internal temperature (USDA/FSIS charts — poultry 74°C, whole cuts 63°C + rest, fish 63°C) and treat time as a function of geometry.

Each food is a row with a reference point and a driver:

type CookingEntry = {
  slug: string;
  safeMinInternalTempC: number | null;
  referenceTempC: number;
  referenceTimeMin: number;
  referenceTimeMax: number;
  referenceThicknessCm: number | null;
  referenceWeightG: number | null;
  keyGeometryDriver: "thickness" | "total_weight";
};

Then the estimate scales the reference time by how far your piece is from the reference, using a power law instead of a linear guess (a steak twice as thick doesn't take twice as long — heat diffusion is closer to thickness²):

const ratio = input.thicknessCm / entry.referenceThicknessCm;
const factor = Math.pow(ratio, 1.2); // clamped to sane bounds
const minutes = referenceCenter * factor * tempFactor;

Is it perfect? No — it's a household estimate, and the page says so and shows the safe temperature so you can verify with a thermometer. But it's honest about where it comes from, which is more than most results give you.

1 entity = 1 indexable page

The whole thing is programmatic SEO: every food, every city, every scenario is its own route under the Next.js App Router.

app/[locale]/cooking/how-long-to-cook/[slug]/page.tsx
app/[locale]/date-time/world-clock/[slug]/page.tsx

Metadata is generated per-entity in generateMetadata, and there's a dynamic app/sitemap.ts that enumerates every dataset entry. The trap here is lastmod: I first set it to new Date(), which re-stamped all ~1,800 URLs as "changed" on every deploy. Crawlers learn to distrust that fast. Fix: a single datasetLastReviewed constant I bump only when the data actually changes.

SQLite is fine (really)

The datastore is SQLite via Prisma. For a read-heavy site with curated datasets it's genuinely fine — no connection pool, no separate DB server, the whole thing is a file you can .backup in a cron job. The dataset itself lives in versioned TSV/JSON, so the DB is more of a cache than a source of truth.

Time zones will humble you

The world-clock pages use the Temporal API (via the polyfill) instead of raw Date, because DST math is where naive code dies:

const zoned = instant.toZonedDateTimeISO("Europe/Prague");
const offsetMin = Math.round(zoned.offsetNanoseconds / 60_000_000_000);

Each page also computes the next clock change by binary-searching for the offset flip, so a "12:00 UTC to Kyiv" page can tell you when the answer will shift. Real IANA zones, date-aware offsets, no static UTC+2 lies.

Two footguns that cost me traffic

www returning 200. Behind a proxy, request.nextUrl.hostname isn't reliable — I had to check Host and X-Forwarded-Host in middleware to 301 www → apex. Until I did, Google had two copies of every page and split the signals.
hreflang x-default pointing at the wrong locale. It decides what Google serves everyone outside your declared locales. Mine defaulted to the non-English version while the inventory targeted English queries. One-line change, big difference.

Stack, for the curious

Next.js (App Router) + TypeScript + Tailwind + Prisma/SQLite, ~1,800 pages generated from curated datasets, deployed with a boring git pull + pm2 restart script. Solo project.

If you want to poke at the actual output, it's live and free (no signups, no paywall): https://theunitools.com/en — I'd genuinely like to hear if a cooking time looks off to you, since that's the part I care about most.