What Will 0.1 + 0.2 Be in JavaScript? Why?

JavaScript, like most programming languages, produces a strange number when we add 0.1 + 0.2, which can cause errors if not handled properly. This is a problem that must be avoided for products that require high numerical precision, such as financial products. Therefore, this is also a common basic question in JavaScript interviews.

What will 0.1 + 0.2 be in JavaScript?

It will be 0.30000000000000004

Why does 0.1 + 0.2 equal 0.30000000000000004?

This is not a unique phenomenon in JavaScript, but a problem encountered by all programming languages that use binary floating-point operations. JavaScript uses IEEE 754 64-bit double precision floating-point numbers, which is why this problem occurs when working with decimal points.

In everyday life, we mostly use decimal, and to accurately express decimal, 10's factors are 5 and 2, so only 1/2, 1/4, 1/5, 1/8, 1/10 can be clearly expressed by decimal; but 1/3, 1/6, 1/7, 1/9 cannot. For example, we know that 1/3 will be 0.33333333 endlessly.

For binary, only 1/2, 1/4, 1/8 can be clearly expressed, while others will continue endlessly. However, because the computer's memory is limited and the program language assigns a limited amount of memory to a number, there are limitations in the expression of accuracy, which is the reason for the strange number 0.30000000000000004.

How to avoid related problems? In JavaScript, there are methods such as toFixed and toPrecision for manipulating numbers, which allow us to set the precision we want. For example, we can set the precision to the first decimal place.

console.log((0.1 + 0.2).toFixed(1)); // 0.3
console.log((0.1 + 0.2).toPrecision(1)); // 0.3

These built-in methods work well for simple cases, but they have limitations. If you're dealing with dynamically calculated numbers, you can't always predict how many decimal places you'll need to specify in toFixed. This is why many developers turn to specialized libraries.

The JavaScript ecosystem offers several battle-tested libraries for precise arithmetic:

There's also an interesting recent project called nstr that takes a different approach. Instead of fixing the math, it focuses on the presentation layer—preventing these weird numbers from ever reaching your users. It's surprisingly compact (about 100 lines) while handling numerous edge cases. Worth checking out the source code if you're curious about elegant problem-solving.

Alternative Approaches: Avoiding Floating-Point Altogether

In high-stakes industries like finance, many teams sidestep floating-point arithmetic entirely. Instead of representing $1.05 as 1.05, they work with integers: 105 cents. This eliminates precision errors at the source.

But integers aren't always practical. Some systems use scaled integers instead—representing $1.05 as 1050000.0, which can accurately handle values from 0.000001 to 9999999999.999999. The precision range depends on your specific requirements.

Languages like Java offer specialized types such as BigDecimal that guarantee precision, but they come with performance trade-offs. Unless you genuinely need that level of precision, simpler scaled-integer approaches usually suffice.

The right choice depends entirely on your context. Consider your precision requirements, performance constraints, and the real-world impact of small errors. Sometimes toFixed(2) is perfectly adequate; other times, you need bulletproof arithmetic.