Precision matters: Handling currency in JavaScript

JS Number is a 64-bit float. It cannot exactly represent values like 0.1, so 0.1 + 0.2 becomes 0.30000000000000004.

In a tax calculator, that tiny error turns into off-by-one-kobo bugs. What is a meme in a todo app is a ticket in production.

Represent currency as the smallest unit: kobo for NGN, cents for USD. NGN 1,234.56 becomes 123456 internally.

Convert to human-readable decimals only at the edges: UI, PDFs, or payment providers. Core business logic stays integer.

BigInt plus a small helper library keeps arithmetic exact and dependency-free across Workers, Node, and browsers.

Decimal libraries (decimal.js, Dinero.js) add APIs for allocation and formatting at the cost of bundle size. Pick one approach and enforce it consistently.

Database DECIMAL columns are fine, but never parse them into floats in JS; keep them as strings or integers before doing math.

Arithmetic helpers that only accept bigint: add, subtract, and apply rates using basis points so percentages stay integer-friendly.

Explicit rounding rules: tax bands round down, gross-to-net rounds to nearest kobo, display always keeps two decimals but leaves the underlying BigInt intact.

User input never becomes a float. Parse strings, validate format, convert to BigInt, and reject malformed entries up front.

Integer smallest units, BigInt logic, explicit rounding, and string-based formatting remove an entire class of money drift bugs.

If your app touches salaries, taxes, invoices, or subscriptions, treat "0.1 + 0.2" as a smell and fix the pattern once.