How to Round Numbers in Java: Math.round(), Decimal Places, BigDecimal, and RoundingMode

1. What “Rounding (四捨五入)” Means in Java

When you want to do “rounding (四捨五入)” in Java, there is actually no single method that always rounds the way you expect.
That’s because in Java, the appropriate rounding approach depends on the numeric type (int / double / BigDecimal, etc.) and the goal (calculation vs display).

In this section, we’ll first organize the core concepts and clarify why rounding in Java can feel confusing.

1.1 Basic Rounding Rule (5 and Up Rounds Up)

The general rounding rule is as follows:

• If the next digit is 5 or greater → round up
• If the next digit is 4 or less → round down

Example (rounding to the ones place)

• 1.4 → 1
• 1.5 → 2

This rule is the same in Java, but the real challenge is “which method applies this rule” and “how many digits you can handle”.

In Java, rounding is typically separated by purpose, such as:

• You just want to round a simple number
• You want to round to the nth decimal place
• You need zero tolerance for error (for example, money calculations)

If you try to handle all of these with the same approach, you’ll often get unintended results.

1.2 Why Rounding in Java Can Be Confusing

The main reasons rounding in Java is often described as “hard” or “not working as expected” are these three points:

Reason 1: Floating-point (double) precision errors

double is a type that represents decimals in binary.
As a result, even numbers that look clean in decimal can include internal precision errors.

Example:

double x = 0.1 + 0.2;
System.out.println(x); // 0.30000000000000004

If you round in this state, you may get results that don’t match human intuition.

Reason 2: You can’t directly “round to the nth decimal place”

Java does not provide a dedicated method like:
“round to 2 decimal places”
out of the box.

So in many cases, you need an adjustment using arithmetic, such as:

• Multiply by 10 or 100
• Round
• Scale back to the original magnitude

If you get the steps wrong, the result will be off.

Reason 3: Methods differ in behavior and return types

For example, Math.round() is convenient, but it returns an integer type (int / long).
If you want to round while keeping decimal places, you can’t use it as-is.

Common Pitfalls and Things to Watch Out For

• Assuming “rounding = Math.round()”
  → Often insufficient for 2+ decimal places or money calculations
• Doing money calculations with double and rounding afterward
  → Errors can accumulate and become risky in real-world systems
• Using the same rounding for display and calculation
  → You may lose precision by rounding internal calculations

Rounding is a process to “clean up the final output,” and the timing and the data type you apply it to are extremely important.

2. Rounding with Math.round() (The Most Basic Approach)

Math.round() is one of the most basic and easiest methods for rounding in Java.
It’s a good first approach for beginners, but you need to understand its valid use cases and limitations to avoid misuse.

In this section, we’ll organize the correct usage of Math.round() and the common pitfalls you’re likely to hit in real development.

2.1 Basic Usage of Math.round()

Math.round() rounds the given number to the nearest integer.

double a = 1.4;
double b = 1.5;

System.out.println(Math.round(a)); // 1
System.out.println(Math.round(b)); // 2

Key points:

• Rounds up when the fractional part is 0.5 or greater
• Rounds down when it’s less than 0.5
• Follows the standard round-half-up style rule

It looks intuitive, but the return type is an important point to watch.

2.2 Watch Out: The Return Type Is int / long

Math.round() changes its return type depending on the argument type.

Example:

double x = 3.7;
long result = Math.round(x);

The key point is: the return value is always an integer type.

In other words, it’s not suitable as-is for cases like:

• You want to keep decimals in the result
• You want to keep 1 or 2 decimal places

because Math.round() itself produces an integer.

Common Mistake Example

double price = 12.34;
double rounded = Math.round(price); // actually long → assigned to double

This code does not cause a compile error, but
the fractional part is completely lost and becomes 12.0, so be careful.

2.3 How to Round to the 2nd Decimal Place or Beyond (×10 / ×100 Technique)

If you want to use Math.round() to round to the nth decimal place,
you typically follow this process:

Steps

1. Multiply the target value by 10ⁿ
2. Round to an integer with Math.round()
3. Divide by 10ⁿ to return to the original scale

Example: Round to 2 Decimal Places

double value = 1.234;
double rounded = Math.round(value * 100) / 100.0;

System.out.println(rounded); // 1.23

Example: Round to 1 Decimal Place

double value = 1.25;
double rounded = Math.round(value * 10) / 10.0;

System.out.println(rounded); // 1.3

This approach is easy, but it does not completely eliminate double-specific precision issues.

Pitfalls, Warnings, and Common Mistakes

• Accidentally doing integer divisionMath.round(value * 100) / 100; // 100 is int → decimals disappear → Always use a double like 100.0
• Using it directly for money calculations
  → OK for display, but often unsuitable for calculations
• Rounding too early
  → If you round intermediate results, the final value can drift

Math.round() is great when you “just want an integer” or “want to round for display,” but you must remember that
it has limitations when accuracy is critical.

3. A Common Way to Round to the Nth Decimal Place

Requests like “I want to round to 2 decimal places” or “I want to keep 3 decimal places” are extremely common, and
this is also the core search intent behind the keyword java 四捨五入.

In this section, we’ll explain a common approach for rounding to the nth decimal place using Math.round(),
and clearly point out its limitations.

3.1 The Basic Formula Pattern

Because Java does not provide a dedicated method for rounding to the nth decimal place,
a widely used approach is to scale the number, round it, and then scale it back.

Basic formula

Math.round(value × 10^n) ÷ 10^n

Example: Round to 2 decimal places

double value = 12.345;
double rounded = Math.round(value * 100) / 100.0;

System.out.println(rounded); // 12.35

Example: Round to 3 decimal places

double value = 12.34567;
double rounded = Math.round(value * 1000) / 1000.0;

System.out.println(rounded); // 12.346

This method is easy to understand and is practical enough for display-only number processing.

3.2 A Case Where It Doesn’t Work Well (The 0.1 + 0.2 Problem)

However, this method cannot completely avoid double precision errors.

A classic example is the following case:

double value = 0.1 + 0.2;
double rounded = Math.round(value * 10) / 10.0;

System.out.println(value);   // 0.30000000000000004
System.out.println(rounded); // 0.3

It may look fine here, but depending on the calculation and the number of digits, you can still get unexpected rounding results.

The following cases are especially risky:

• Money calculations
• Cumulative calculations for tax rates or percentages
• Rounding repeatedly inside loops

3.3 Why Errors Happen (Very Brief Explanation)

double is a floating-point type that represents decimals in binary.
So even values that are exact in base-10 can include small errors in their internal representation.

This is a Java specification detail, not a bug.

Common misunderstandings

• “My formula is wrong” → ❌
• “Java is broken” → ❌
• “It’s due to the nature of double” → ✅

Pitfalls, Warnings, and Common Mistakes

• Getting the scaling/division order wrongMath.round(value) * 100 / 100.0; // meaningless
• Using an integer in the divisionMath.round(value * 100) / 100; // decimals disappear
• Rounding repeatedly during intermediate steps
  → makes errors accumulate more easily

This method is “easy and fast,” but you must understand that it can be insufficient when accuracy is required.

4. Accurate Rounding with BigDecimal (Recommended)

For money calculations, tax calculations, and other workflows where errors are not acceptable, rounding with double and Math.round() is not appropriate.

In such cases, the recommended approach is to use BigDecimal.
BigDecimal is a class that can handle base-10 numbers accurately, and it is the standard solution in Java for “accurate rounding.”

4.1 When You Should Use BigDecimal

You should use BigDecimal for cases like these:

• Money calculations (prices, invoices, balances)
• Rate-based calculations such as tax rates and interest rates
• Accounting, finance, and business systems
• Processing where rounding results must be reproducible

If the calculation result itself matters (not just display), it’s safer to choose BigDecimal instead of double.

4.2 The Correct Way to Create BigDecimal (new vs valueOf)

The most common pitfall with BigDecimal is creating it the wrong way.

❌ Incorrect example (not recommended)

BigDecimal bd = new BigDecimal(1.23);

This carries over the precision error from double.

✅ Correct examples (recommended)

BigDecimal bd1 = new BigDecimal("1.23");
BigDecimal bd2 = BigDecimal.valueOf(1.23);

• String constructor: safest option
• valueOf: safe because it converts internally via String

Rule of thumb: avoid new BigDecimal(double).

4.3 How to Use setScale() and RoundingMode

To round with BigDecimal, you typically combine
setScale() with RoundingMode.

Example: Round to 2 decimal places

import java.math.BigDecimal;
import java.math.RoundingMode;

BigDecimal value = new BigDecimal("12.345");
BigDecimal rounded = value.setScale(2, RoundingMode.HALF_UP);

System.out.println(rounded); // 12.35

• 1st argument: number of decimal places to keep
• 2nd argument: rounding rule

RoundingMode.HALF_UP corresponds to the typical “round half up” rule (5 and up rounds up).

Pitfalls, Warnings, and Common Mistakes

• Not specifying RoundingModevalue.setScale(2); // may throw an exception
• Doing double → BigDecimal → rounding in the wrong order
  → Use BigDecimal from the beginning
• Mixing up display vs calculation
  → Use BigDecimal for calculation; format only when displaying

BigDecimal adds more code, but it is essential whenever accuracy and safety are the top priorities.

5. RoundingMode Types and Differences

When you round with BigDecimal, the key concept you must understand is RoundingMode (rounding mode).

RoundingMode explicitly defines “which rule to use,” and in practice it should be considered mandatory, because not specifying it makes the behavior ambiguous.

5.1 HALF_UP (Typical rounding)

RoundingMode.HALF_UP corresponds to the most common definition of rounding.

Rule

• If the next digit is 5 or greater → round up
• If the next digit is 4 or less → round down

Example

BigDecimal value = new BigDecimal("2.345");
BigDecimal rounded = value.setScale(2, RoundingMode.HALF_UP);

System.out.println(rounded); // 2.35

If you don’t have a special reason, choosing HALF_UP for rounding is usually correct.

5.2 How It Differs from HALF_DOWN / HALF_EVEN

RoundingMode includes several rounding styles with similar names.
Many people get confused here, so let’s clarify the differences.

HALF_DOWN

• If the next digit is exactly 5, round down

2.345 → 2.34

HALF_EVEN (Bankers’ rounding)

• If the next digit is exactly 5, round toward the nearest even number

2.345 → 2.34
2.355 → 2.36

HALF_EVEN is used to reduce systematic rounding bias and can be specified in finance or statistics standards, but it’s unnecessary for most general business cases and beginner-friendly code.

5.3 How to Choose

If you’re unsure, the decision rule is straightforward:

• Typical rounding → HALF_UP
• Finance/regulated domain with a defined standard → follow the specification
• No special reason → HALF_UP only

Common mistakes

• “Using HALF_EVEN just because”
• “Copy-pasting without understanding the difference”

Rounding modes are part of your system specification.
You should not change them without a clear reason.

Pitfalls, Warnings, and Common Mistakes

• Omitting RoundingMode
  → may cause runtime exceptions
• Assuming rounding always means HALF_UP
  → may conflict with business specs
• Rounding rules not standardized within the team
  → can lead to inconsistent calculation results

6. Common Pitfalls, Warnings, and Failure Examples

Rounding in Java is an area where it’s easy to make mistakes even if you know the syntax and APIs.
In this section, we’ll summarize mistakes that beginners to intermediate developers commonly make, and clearly explain “why it’s wrong” and “how to avoid it.”

6.1 Doing money calculations with double

This is both the most common and the most dangerous mistake.

double price = 1000.0;
double tax = price * 0.1;
double total = price + tax;

It may look fine at first glance, but
since double is a type that can include precision errors,
it introduces the risk of incorrect results in money calculations.

Correct mindset

• For calculation: BigDecimal
• For display: rounding/formatting

BigDecimal price = new BigDecimal("1000");
BigDecimal tax = price.multiply(new BigDecimal("0.1"));
BigDecimal total = price.add(tax);

6.2 Getting the rounding order wrong

With rounding, when you apply it matters.

❌ Bad example

double a = Math.round(x * 100) / 100.0;
double b = Math.round(a * y * 100) / 100.0;

If you round repeatedly during intermediate steps, errors accumulate.

✅ Basic guideline

• Complete all calculations first
• Apply rounding only once to the final result

6.3 Mixing display rounding with calculation rounding

If you mix up “rounding for display” with “rounding for internal calculations,” your design will break down.

Common misunderstandings

• Using a display-rounded value in the next calculation
• Changing calculation logic to match UI requirements

Correct separation

• Internal calculation: prioritize precision (BigDecimal)
• Display: formatting/rounding

6.4 Not standardizing RoundingMode

If different parts of your code use a mix of
HALF_UP, HALF_DOWN, and HALF_EVEN,
you can end up with inconsistent results from the same calculation.

Countermeasures

• Define the rounding rule as a constant
• Standardize it across the team/project

static final RoundingMode ROUND_MODE = RoundingMode.HALF_UP;

Summary of Common Pitfalls

• Just because double “can calculate” doesn’t mean it’s “accurate”
• Round only once, at the end
• Treat rounding rules as part of your specification
• Separate calculation and display

Keeping these in mind helps you avoid most rounding-related issues.

7. Quick Reference: Which Method to Use (By Use Case)

As explained so far, Java has multiple ways to round numbers, and the key point is not “which one is correct,” but that
the correct choice depends on the use case.

In this section, we’ll organize practical method selection by scenario so readers can decide quickly.

7.1 If You Want a Simple Integer → Math.round()

Typical use cases

• You want to display a computed value as an integer
• Counts, number of people, rating points, etc.
• Processing where precision errors are not an issue

Recommended approach

long result = Math.round(value);

Notes

• The return type is int or long
• Not suitable if you need to keep decimals

👉 If you “just want an integer,” use Math.round().

7.2 If You Want to Display Up to N Decimal Places → Math.round() + Scaling

Typical use cases

• Numbers for UI display
• Reports and log output
• Cases where strict precision is not required

Recommended approach (2 decimal places)

double rounded = Math.round(value * 100) / 100.0;

Notes

• double precision errors still remain
• Do not use for calculation data

👉 Acceptable only for display

7.3 Money, Tax, Business Logic → BigDecimal + HALF_UP

Typical use cases

• Money, billing, payments
• Tax rates and discount rates
• Business logic and persisted data

Recommended approach

BigDecimal rounded =
    value.setScale(2, RoundingMode.HALF_UP);

Why

• Handles base-10 numbers accurately
• Makes rounding rules explicit
• Ensures reproducibility

👉 This is effectively the standard approach in real-world systems

7.4 A Simple Decision Flow When You’re Unsure

• “Is some error acceptable?”
  • YES → Math.round()-based approaches
  • NO → BigDecimal
• “Will you save/reuse the result?”
  • YES → BigDecimal
  • NO (display only) → Math.round()

Common Mistakes (Method selection)

• Reusing display-only code in business logic
• Continuing to use double for money values
• Overusing Math.round() “because it’s easy”

Once you organize method selection, you can significantly reduce the cost of future spec changes and bug fixes.

FAQ (Frequently Asked Questions)

Q1. What is the easiest way to round in Java?

A. If you simply want to round to an integer, Math.round() is the easiest. However, the return type is an integer, so you can’t keep decimals.

Q2. How do I round to 2 decimal places (or the nth decimal place)?

A. For display purposes, scale the number like:
Math.round(value * 100) / 100.0
If you need accuracy, use BigDecimal.setScale().

Q3. Why do results drift even though I’m using Math.round()?

A. This is caused by floating-point precision errors in double. It’s part of Java’s behavior, not a bug.

Q4. Should I avoid Math.round() for money calculations?

A. Yes, it’s not recommended. For money and tax calculations, it’s safer to use BigDecimal and round with RoundingMode.HALF_UP.

Q5. I’m using BigDecimal but still seeing errors sometimes

A. You may be using new BigDecimal(double).
Use new BigDecimal("1.23") or BigDecimal.valueOf(1.23) instead.

Q6. Which RoundingMode should I choose?

A. For typical rounding, RoundingMode.HALF_UP is a safe default. If your domain has a defined standard/specification, follow it.

Q7. Is it okay to round during intermediate calculations?

A. Not recommended. Rounding during intermediate steps makes errors accumulate, so the basic rule is to apply it only to the final result.

Q8. Should I separate rounding for display vs rounding for calculations?

A. Yes.

• For calculations: BigDecimal (precision first)
• For display: Math.round() or formatting
  Separating them is the correct design.