Rounding Calculator
Round to decimal places, significant figures or the nearest multiple, with the tie-breaking rule named on every result. It rounds the number you typed rather than the binary approximation of it, which is why it can answer 1.01 for 1.005 where most programming languages answer 1.00.
Round to a fixed number of digits after the point. A negative count rounds to the left of the point instead: −3 rounds to the nearest thousand.
Half up. Nearest neighbour; an exact midpoint goes up the number line, toward +∞. So 2.5 → 3 and −2.5 → −2. This is what most people were taught at school, and it is not symmetric about zero.
2.675 sits exactly halfway between 2.67 and 2.68. That is a tie, and the tie rule is what decides it: Half up sends ties up the number line, so the answer is 2.68.
The same number under all ten rules. Where they disagree none of them is wrong; they are different rules, and this is exactly where two spreadsheets quietly stop matching.
| Rule | Result | Where you meet it |
|---|---|---|
| Half up · your rule | 2.68 | JavaScript Math.round(), school rounding |
| Half down | 2.67 | rare on its own; the mirror of half up |
| Half to even (banker's) | 2.68 | IEEE 754 default, Python round(), C# Math.Round(), NumPy |
| Half to odd | 2.67 | some signal-processing code; uncommon elsewhere |
| Half away from zero | 2.68 | Excel ROUND(), PHP round(), Java BigDecimal HALF_UP, most SQL engines |
| Half toward zero | 2.67 | Java BigDecimal HALF_DOWN |
| Ceiling | 2.68 | Math.ceil(), Excel CEILING() |
| Floor | 2.67 | Math.floor(), Excel INT() |
| Truncate (toward zero) | 2.67 | Math.trunc(), Excel TRUNC(), integer casts in C, Go and Rust |
| Away from zero | 2.68 | Excel ROUNDUP() |
Common questions
- Why do calculators disagree about rounding 1.005 to two decimal places?
- Because 1.005 cannot be stored exactly in binary floating point. What actually sits in memory is 1.00499999999999989341858963598497211933135986328125, which is below the halfway point, so most languages round down to 1.00, which is correct for the number they were given. This tool works on the digits you typed as an exact decimal, so it treats 1.005 as exactly 1005/1000 and rounds to 1.01. Neither is a bug; they are answers to different questions, and the tool tells you when the two diverge.
- What are the tie-breaking rules and which should I use?
- Half up sends exact halves away from zero for positives (2.5 → 3) and is what most people mean by rounding. Half even, also called banker's rounding, sends them to the nearest even digit (2.5 → 2, 3.5 → 4) and is the IEEE-754 default that spreadsheets and most languages use, because it stops repeated rounding from drifting upward. Half down and half away from zero cover the remaining conventions. The rule used is always named beside the result.
- Why do the rules differ on negative numbers?
- Because "up" is ambiguous once you cross zero. Half up takes −2.5 to −2, since −2 is the larger number. Half away from zero takes it to −3, since 3 is the larger magnitude. Both are called "round half up" in different documentation, which is exactly why this tool names the rule rather than assuming one.
- What is the difference between decimal places and significant figures?
- Decimal places count digits after the point; significant figures count meaningful digits from the first non-zero one. 0.001234 to three decimal places is 0.001, which throws away nearly all the information. To three significant figures it is 0.00123, which preserves it. Measurements are almost always better expressed in significant figures.
- Can I round to the nearest 5, 25 or 0.1?
- Yes. Nearest-multiple rounding handles any step, which is what you want for pricing, time increments or stock quantities. Rounding to a multiple of zero has no meaning and returns an explanation rather than a division-by-zero error.
- Does it handle very large or very small numbers?
- Yes, without loss. Because the arithmetic is exact-decimal on arbitrary-precision integers rather than doubles, a number with hundreds of digits rounds correctly and the digits you did not round stay exactly as you typed them.
Exact, with one stated interpretation. All arithmetic is exact-decimal integer division on BigInts, with no floating point anywhere in the answer path, so results are correct to the last digit at any magnitude. Where treating your input as an exact decimal changes the answer, the page says so and shows both.