Skip to main content
CalcMax

Round to the Nearest Cent Calculator

Range: -1,000,000,000 – 1,000,000,000

Result

2.68

Rounded value

Cents
268

Rounding an amount to the nearest cent means cutting it to two decimal places, with amounts exactly half a cent going away from zero: 2.675 becomes 2.68 and 0.005 becomes 0.01. It is the last step of almost every money calculation, because a price times a quantity, or a rate applied to a subtotal, almost never lands exactly on a whole number of cents. Doing it correctly is harder than it looks. The straightforward approach multiplies by 100, rounds to a whole number and divides back, and that fails on precisely the amounts people care about: 1.005 multiplied by 100 is 100.49999999999999 rather than 100.5, so the number rounds down to 1.00 and the last cent silently disappears. Printing the value to two decimals instead has the same problem for the same reason, since it is looking at the same slightly-too-small number. Neither failure announces itself. The output is a perfectly ordinary-looking amount, and the only way to notice is to know what it should have been. This page avoids the trap by moving the decimal point as text rather than by multiplying, so the decision is made on the exact value. It also reports the amount as a whole number of cents, which is the form worth keeping when you are going to do more arithmetic with it. The result is written the way your language writes money: an English reader sees one thousand two hundred thirty-four and fifty-seven hundredths as 1,234.57, while a German reader sees the same amount as 1.234,57. Two amounts that differ only in the last cent come back as different numbers, which is the whole point.

Four amounts that look ordinary and round the wrong way

AmountRoundedCents
2.6752.68268
1.0051.01101
0.0050.011
-0.005-0.01-1

Every row here is an amount that a straightforward implementation gets wrong, and each one fails for its own reason. 2.675 is the example everybody uses and it is the one case where scaling by a hundred happens to work, since it lands exactly on 267.5 — so it is a bad sample and a good warning, because a reader who checks only this row will find their own code agrees and conclude there is nothing to fix. 1.005 is the real failure: a hundredth has no exact binary form, so scaling it gives 100.49999999999999 and both of the obvious methods answer 1.00. 0.005 is exactly half a cent and goes away from zero, which on a positive amount is the same as going up. And -0.005 is the same amount with a sign, where the two rules part company: rounding a negative half toward positive infinity gives a negative zero, which prints as -0.00. The third column runs alongside so that each row also shows the two views of one amount — the decimal on the left of it, the whole number of cents on the right, computed from the rounded amount so that the two can never disagree.

Formula

2.675 -> 2.68; 1.005 -> 1.01; 0.005 -> 0.01; -0.005 -> -0.01; cents = rounded * 100

value
The amount to round, from minus a billion to plus a billion. More than two decimals are accepted on purpose: 1.005 and 2.675 are exactly what this page is for, and an input that refused them would turn away the cases it exists to handle. The field does not enforce two decimals, and it should not — the rounding rule is the subject, not the input format
rounded
The amount after rounding to two decimal places, and the first row of the result. It is a number rather than a piece of text, which is the reason it is written with your language's decimal separator and thousands grouping: 1234.57 in English, 1.234,57 in German. That difference from the general rounding page is deliberate and is the only one on the same input
cents
The same amount expressed as a whole number of cents, which is a separate output rather than a second way of writing the first one. 268 is an integer you can add, split and count with; 2.68 is a decimal that turns back into a float the moment you multiply it by anything. It is computed from the rounded amount rather than from the original, so the two rows can never disagree — 1.005 gives 1.01 beside 101, never 1.01 beside 100
half away from zero
The rule for amounts sitting exactly half a cent: 0.005 goes to 0.01 and -0.005 goes to -0.01. Rounding up and rounding away from zero agree on positive amounts and differ on negative ones, which is where the distinction earns its keep — the naive integer method returns a negative zero here, and -0.00 is not a thing anyone should be shown as an amount owed
1.005 * 100 = 100.49999999999999
The failure this page is built around. A hundredth cannot be stored exactly in binary, so scaling by a hundred lands just under the half-way point and the rounding goes the wrong way. Every method that multiplies first, whether it then rounds the number or formats it to two decimals, inherits that error and answers 1.00. Moving the decimal point in the text instead keeps the value exact, and the answer comes out 1.01
-0.005 -> -0.01
The negative half-cent, and the case where the two rounding rules part company. The amount is exactly half a cent below zero, and the rule sends it further from zero rather than upward, so it becomes -0.01 rather than -0.00. Rounding a negative half toward positive infinity gives a result of negative zero, which prints as -0.00 and reads as a rounding error even though the arithmetic was consistent

Any calculation that ends in money ends here. A bill split between several people almost never divides into whole cents, and the remainder has to be assigned to someone or rounded away; a tax or a tip rate applied to a subtotal produces an amount with more decimals than money has; and a unit price times a quantity does the same. Rounding at the end is the obvious step, but the one that matters more is rounding in the middle. An amortisation schedule computes interest on the balance each period and rounds every period's interest to the cent before adding it back, because rounding only at the end lets the fractional parts accumulate — over three hundred and sixty periods that drift is whole dollars, and the final balance stops matching the lender's. The same reasoning applies wherever a total is built from rounded parts: the parts have to be rounded first and then added, not the other way round. The number of cents is the form to keep for that kind of work, since it is an integer and stays exact all the way through. Where the question is about decimal places in general rather than about money — a measurement to three decimals, a figure to two significant digits — the rounding page covers thirteen different targets in one place; this page covers the one target that money uses, and does it with a rule that the arithmetic cannot get wrong.

Worked examples

  1. The default amount: 2.675

    1. The amount is between 2.67 and 2.68, and it sits exactly halfway between them
    2. A half goes away from zero, so the answer is 2.68 rather than 2.67
    3. Multiply the rounded amount by 100: 2.68 × 100 = 268
    4. The answer is an amount of two dollars and sixty-eight cents, or 268 cents

    The example everyone reaches for, and the default here for that reason. It is also the one case where the naive method happens to give the right answer, since 2.675 times 100 lands exactly on 267.5 in binary while 1.005 does not — so if this were the only sample on the page, a reader checking it against their own code would find the two agreed and conclude there was no problem to solve. The next example is the one that shows the difference, which is why the page leads with this amount on screen and uses the other one below.

  2. The amount that catches everyone: 1.005

    1. The amount sits exactly halfway between 1.00 and 1.01
    2. A half goes away from zero, so the answer is 1.01
    3. Scaling by a hundred gives 100.49999999999999 rather than 100.5, because a hundredth has no exact binary form
    4. A method that multiplies first therefore rounds down and answers 1.00, losing a cent
    5. Moving the decimal point in the text keeps the value exact, so 1.01 is what comes out

    The example this page exists for. Multiply it by a hundred and you get 100.49999999999999 — not a hair under the halfway point by accident, but because 1.005 is not exactly representable in binary and the stored value is a hair under. Both of the obvious methods inherit that error: rounding the scaled number gives 1.00, and formatting the value to two decimals gives 1.00 as well, because they are looking at the same slightly-too-small number. Nothing about the output looks wrong. One cent is simply gone, and the only way to catch it is to know what the answer should have been. Half-cent amounts like this are exactly where money calculations land, since a rate applied to an odd price produces them constantly.

  3. An ordinary amount with too many decimals: 1234.5678

    1. The first two decimals are 56, and what follows is 78 — more than half of a cent
    2. So the second decimal goes up: 1234.57
    3. Multiply by 100: 1234.57 × 100 = 123457
    4. Written out, the amount is one thousand two hundred thirty-four and fifty-seven cents

    The unremarkable case, and worth one example so that the page is not all traps. Nothing tricky happens: the third decimal is 7, so the amount rounds up in the ordinary way and both methods agree with each other. What this case does show is the formatting, which is the difference a reader notices first. In English the amount comes back as 1,234.57 with a comma grouping the thousands and a full stop before the cents; in German it comes back as 1.234,57 with the two swapped; in French it comes back with a space where the comma was. The digits are identical and the page does not touch them — what changes is how your language writes money, and this page follows it while the general rounding page deliberately does not.

  4. A half cent below zero: -0.005

    1. The amount sits exactly halfway between zero and minus one cent
    2. A half goes away from zero, which here means downward: -0.01
    3. Multiplying by 100 gives exactly -0.5, so this one scales cleanly
    4. Rounding -0.5 to a whole number the naive way gives negative zero, which prints as -0.00
    5. Moving the decimal point in the text gives -1 cent, and -0.01 as the amount

    The case that separates the two rounding rules. On positive amounts, rounding half upward and rounding half away from zero agree, so the distinction looks like hair-splitting. Here they part: rounding -0.5 upward gives zero with a negative sign attached, and an amount of negative zero cents is not something anyone should be shown. This one also scales cleanly, since -0.005 times 100 is exactly -0.5 — the binary failure is not symmetric with the sign, which is why a suite of test amounts needs negatives as well as positives. A refund, a credit or a discount that exceeds the amount all arrive here.

Limitations

The amount must be a number from minus a billion to plus a billion, and the rounded result may sit one step outside that range: 999999999.999 rounds up to a billion exactly, and the cents output is a hundred thousand million. Outputs stay exact at that size because a whole number of cents that large is still inside the range where whole numbers are represented precisely. The rounding rule is half away from zero, and there is no setting to change it — a page with a rule switch would have to explain which rule the courts in your country use, and it does not. Negative amounts are rounded away from zero, not upward, and the two differ on exactly the half-cent cases. The page does not carry a currency: it knows how many cents an amount comes to but not what those cents are called, so the output is a number and any symbol is yours to add. It rounds one amount at a time and does not split a total between people, assign remainders or balance a schedule. The reference table below shows four fixed amounts rather than following your input, and the numbers in it are printed without localisation, so they read 2.675 and -0.005 in every language even though the result panel above does localise.

Frequently asked questions

Why is 1.005 rounded to 1.01 rather than 1.00?
Because it is exactly half way between 1.00 and 1.01, and the half-way rule sends an amount away from zero. The answer looks like the surprising one only because the obvious implementations return 1.00 instead. Multiply 1.005 by a hundred and you get 100.49999999999999, not 100.5 — a hundredth cannot be stored exactly in binary, and the value that gets stored is a hair below the real one. So a method that scales first, whether it then rounds the number or formats it to two decimals, is looking at a value slightly under the half-way point and rounds down. The cent does not go missing loudly; the output is an ordinary-looking amount. This one input is the reason there is a page here rather than a one-line formula.
Does it round half up or half to even?
Half away from zero — upward on positive amounts, downward on negative ones. That is what almost every cash system does and what a person means by rounding a price, so 2.5 cents becomes 3 and -2.5 cents becomes -3. Rounding half to even is the other common rule, and it exists to stop long columns of numbers drifting upward when they are added; it matters in statistics and in some accounting work, and it is not what this page does. The two rules agree on every amount except the exact halves, which is why the difference is easy to miss until a payout lands on one. There is no switch, because a switch would need an explanation of which rule applies to which jurisdiction.
Why report the number of cents as well as the amount?
Because the two are useful for different things, and the whole number is the one that stays exact. Two hundred and sixty-eight is an integer: you can add it to other whole cents, split it between people, multiply it by a quantity and keep going without anything happening to it. Two point six eight is a decimal, and the moment you multiply it by something it becomes a floating point number again with the same representation problem you came here to avoid. That is also why the cents are computed from the already-rounded amount rather than from the original input — if they were computed separately, an input like 1.005 could print 1.01 on one row and 100 on the next, and two numbers on the same panel disagreeing is worse than either being slightly off.
Why does the result use a comma in some languages?
Because money is written the way the reader's language writes it, and that is not the same everywhere. English puts a full stop before the cents and commas between thousands, so the amount comes out as 1,234.57. German and most of continental Europe do it the other way round: 1.234,57. French uses a space where the comma was: 1 234,57. The page reports the amount as a number rather than as a piece of text, so the formatting follows the language you are reading in. The general rounding page on this site deliberately does not do this — its result is text with a fixed full stop and no grouping — and that is the one place the two pages genuinely differ on the same input.
Where does rounding to the cent actually matter?
Anywhere a total is assembled from parts. An amortisation schedule is the clearest case: each period's interest is computed on the remaining balance, rounded to the cent, and added back, and doing the rounding only once at the end lets the leftover fractions accumulate — across three hundred and sixty periods that drift is whole dollars and the final balance stops agreeing with the lender's. Splitting a bill has the same shape, since a total divided between several people rarely lands on whole cents and the odd cent has to go somewhere. And every rate applied to an amount — tax, a tip, a discount — produces more decimals than money has. The rule to carry away is that the parts get rounded first and the rounded parts get added, rather than the other way round.
What is the largest amount the page accepts?
A billion, in either direction, and the rounded answer is allowed to sit one step outside that — 999999999.999 rounds up to exactly a billion, and the cents output there is a hundred thousand million. Outputs stay exact at that size because a whole number of cents that large is still inside the range where every whole number is represented precisely; the ceiling is well below the point where whole numbers start being approximated. Inputs past the bound are refused rather than clamped, since quietly rounding an amount you did not type would be a worse answer than saying no.

References

Related calculators