Expression Evaluator
Type an arithmetic expression and get the result, with operator precedence and parentheses handled properly. The value over a basic calculator is that a chain of operations is evaluated as a whole rather than left to right, which is where sequential-entry calculators go wrong.
How to use it
- Type an expression using +, -, *, /, and parentheses.
- The result is computed in the page as you type.
- Use parentheses to force the grouping you intend.
Precedence, and why calculators disagree
Multiplication and division bind more tightly than addition and subtraction, and are evaluated left to right among themselves. So 2 + 3 times 4 is 14, because the multiplication happens first, not 20.
A basic four-function calculator with sequential entry gives 20, because it applies each operation as you press the key with no lookahead. Scientific and graphing calculators, spreadsheets, and programming languages all respect precedence and give 14. Both devices are consistent with their own design, which is precisely why a result copied from one and checked on the other does not agree.
Left-to-right evaluation among equal-precedence operators matters more than it appears. 100 divided by 5 times 2 is 40, since the division comes first. Reading it as 100 divided by (5 times 2) gives 10. The expression as written has one correct answer, but the intent behind it frequently is the other one, which is an argument for parenthesising anything ambiguous rather than relying on the reader knowing the rule.
Where the notation is genuinely ambiguous
Some expressions have no universally agreed reading, and no evaluator can resolve them correctly because there is nothing to be correct about.
Implicit multiplication next to division is the well-known case: 6 divided by 2(1+2). Treating implicit multiplication as equal in precedence to explicit division and going left to right gives 9. Treating juxtaposition as binding more tightly gives 1. Different textbooks, different calculator manufacturers, and different computer algebra systems genuinely disagree, and the expression is simply badly written.
Unary minus with exponentiation is another. Whether minus two squared means negative four or positive four depends on whether the minus is part of the number or an operator applied afterwards. Spreadsheets and most programming languages disagree with each other here.
The resolution is not to learn a rule but to write parentheses. An expression that needs a convention to disambiguate should be rewritten, and this evaluator supports parentheses precisely so that you never have to rely on one.
Floating-point results are approximate
Arithmetic here uses binary floating point, which cannot represent most decimal fractions exactly. The classic demonstration is that 0.1 plus 0.2 gives 0.30000000000000004.
The cause is the same as one third being 0.3333 recurring in decimal: one tenth is a recurring fraction in binary and has to be truncated. The error is tiny — about one part in ten quadrillion — but it is real and it accumulates over long chains of operations.
For everyday arithmetic this never matters. It matters when comparing two computed values for exact equality, which can fail for numbers that should be identical, and it matters for money, which is why financial systems store amounts as integer cents or use decimal types rather than floating point. If you are summing thousands of currency values and need the total to reconcile to the penny, this is not the right tool.
Evaluating untrusted expressions safely
The obvious way to evaluate a string of arithmetic in JavaScript is eval, and it is the wrong way. eval executes arbitrary code with full access to the page, so an expression containing anything other than arithmetic runs as a program. The Function constructor has the same problem.
The correct approach is to tokenise the input, validate that every token is a number, a recognised operator, or a parenthesis, and evaluate the resulting structure — commonly by converting to postfix notation via the shunting-yard algorithm, or by a small recursive-descent parser. Anything unrecognised is rejected rather than executed.
This evaluator parses rather than executes, which is why it accepts arithmetic and nothing else. It is also why the input stays in the page: there is no server involved in the calculation at any point.
At a glance
| Operators | Addition, subtraction, multiplication, division |
|---|---|
| Grouping | Parentheses, nested to any depth |
| Precision | IEEE 754 double, approximate for decimal fractions |
| Transmitted | Nothing, parsed locally without eval |
Frequently asked questions
Why does my phone calculator give a different answer?
Basic calculators use sequential entry and apply each operation as you press it. For 2 + 3 times 4 that gives 20; precedence-aware evaluation gives 14.
What is 6 / 2(1+2)?
Genuinely ambiguous. Depending on how implicit multiplication is ranked it is 9 or 1, and authorities disagree. Add parentheses.
Why does 0.1 + 0.2 not give exactly 0.3?
Binary floating point cannot represent one tenth exactly, just as decimal cannot represent one third. The error is about one part in ten quadrillion.
Is this safe with arbitrary input?
Yes. The expression is tokenised and parsed rather than passed to eval, so only arithmetic is accepted and nothing is executed as code.
Read more
Everyday math — A 50 percent gain and a 50 percent loss leave you down 25 percent, and that is the least surprising thing here.