Using if...else in Java for Two-Way Decisions

Here is the smallest complete example that does something useful. Read it, then run it in your head.

int number = 17;
int remainder = number % 2;
if (0 == remainder) {
    System.out.println(number + " is EVEN");
} else {
    System.out.println(number + " is ODD");
}

Change 17 to 16 and the output flips. That is the entire concept. The if block handles one case, the else block handles everything else.

For the single-condition version on its own, we have a separate page on the Java if statement. This page is about what happens when you have two paths.

This sounds obvious, but it is the reason if...else is so useful. You never have to check whether both failed, and you never need a fallback at the end. When you have two paths and you want to be certain one of them happens, this is the tool.

Two practical consequences follow from it. First, code after a complete if...else runs either way, so you should not expect it to be "the case where neither matched". Second, because exactly one branch runs, anything you declare inside one branch is simply not there in the other. We will come back to that in the scoping section, because it catches everyone eventually.

The condition is just a boolean expression, so anything that produces true or false is allowed. The most common beginner mistake is not about if...else at all, it is about writing the condition.

Two of those deserve a warning. First, == does not compare text in Java. It compares references, meaning it asks "are these the same object in memory", which is not the same question as "do these words match". For text you need equals(). The one exception is null, where == is exactly right and equals() would crash.

Second, a character is not a string. A single letter uses single quotes, so 'a' is a char and "a" is a String. They are not interchangeable, and comparing a char to a String with == will quietly be always false rather than throwing an error, which makes it a genuinely nasty bug to track down.

All the comparison and logical operators are covered in detail on our relational comparisons page and our logical operators page.

Java lets you write an if without braces when there is only one statement, and beginners often do this to save typing. Do not. Here is exactly what goes wrong.

// BROKEN: the else attaches to the INNER if, not the outer one
if (hasAccount) if (isVerified) grantAccess();
else showVerificationWarning();
// belongs to the inner if!
// CORRECT: braces make the grouping explicit
if (hasAccount) {
    if (isVerified) {
        grantAccess();
    } else {
        showVerificationWarning();
    }
}

In the broken version, the else silently pairs with the nearest unmatched if, which is the inner one. So when hasAccount is true but isVerified is false, the warning shows, which is probably what you wanted. But when hasAccount is false, the whole inner statement is skipped and nothing happens at all, which is almost certainly a bug.

The general lesson, which applies well beyond if...else, is that indentation is for humans and braces are for the compiler. If you rely on indentation alone, a single auto-format or copy-paste can change the meaning of your program without changing a single character of logic.

Each block has its own scope, which means a variable declared inside a branch simply does not exist outside it. This is worth seeing early, because it is one of the most common compile errors in Java.

int score = 75;
int passMark = 50;
if (score > passMark) {
    String message = "You passed";
    // declared inside the block
    System.out.println(message);
}// System.out.println(message);   // ERROR: message does not exist here

The fix is not to move everything outward, which is the usual beginner reaction. The better fix is to declare the variable where you actually use it, and if you genuinely need a value afterwards, return it from the method or restructure the code.

There is one rule that catches even experienced people: you cannot redeclare a variable from the enclosing scope inside the block, but you can reassign it.

int total = 0;
if (true) {
    total = 50;
    // fine: assigning the existing variable
    // int total = 50; // ERROR: redeclaring the outer total
}

More detail on how long variables live is on our Java scope explained page.

If your condition uses a Boolean object rather than a primitive boolean, the object might be null, and unboxing it throws a NullPointerException at exactly the wrong moment.

Boolean flag = getFlag();
// the wrapper type, may be null
// DANGEROUS: throws NullPointerException when flag is null
if (flag) {
    System.out.println("on");
}// SAFE: short-circuit evaluation skips the second test
if (flag != null && flag) {
    System.out.println("on");
}

Why does the safe version work? Because Java evaluates the left side of && first. If flag != null is false, the right side is never evaluated, so the null never gets unboxed. Reverse the order and you are back to crashing.

The cleanest fix is to avoid the wrapper entirely and use a primitive boolean, which cannot be null. We explain the difference on our autoboxing and unboxing page.

if...else is the right tool when the decision is a genuine either-or and each branch does real work. It becomes a problem in three common situations.

The Early Return Pattern

This one habit makes real code noticeably cleaner. Instead of nesting the main work inside an else, handle the unusual case first and return, then let the normal path continue unindented.

// HARDER TO READ: the main work is buried and indented
int adultAge = 18;
String label;
if (age >= adultAge) {
    if (hasId) {
        label = "adult with id";
    } else {
        label = "adult without id";
    }
} else {
    label = "minor";
}// EASIER TO READ: unusual cases leave early, main path stays flat
String label;
if (age < adultAge) {
    label = "minor";
} else if (!hasId) {
    label = "adult without id";
} else {
    label = "adult with id";
}

The second version keeps the interesting path at the left margin, which is much easier to scan as more checks get added. For three or more branches like this, a switch expression is usually clearer still, and we cover both on our Java switch statement page.

For the compact version, see the Java conditional and ternary operator. Use it sparingly, because a long ternary chained across several lines is harder to read than a plain if block.

Short, complete programs showing if...else in situations you will actually meet.

Example A, Discount Eligibility

int total = 1200;
int minimumForDiscount = 500;
boolean isMember = true;
if (isMember && total >= minimumForDiscount) {
    int discount = total / 10;
    int finalPrice = total - discount;
    System.out.println("You saved 10% and now pay " + finalPrice);
} else {
    System.out.println("No discount. You pay " + total);
}

Note the && combining two conditions. That is a very common shape, and short-circuit evaluation means the discount logic only runs when both are true.

Example B, A Safe Null Check Before Use

String username = getUsername();
if (username == null || username.isBlank()) {
    System.out.println("No username supplied, using Guest");
} else {
    System.out.println("Welcome back, " + username);
}

The || here is what makes it safe. If username is null, the left side is true and Java never evaluates the right side, so isBlank() is never called on a null reference.

Example C, A Grading Decision

int marks = 87;
int topMark = 90;
if (marks >= topMark) {
    System.out.println("Grade A");
} else {
    System.out.println(marks >= 75 ? "Grade B" : "Needs work");
}

That inner ternary shows when nesting is reasonable. One small ternary inside a branch is easy to read; a ternary nested five levels deep is not.

Frequently Asked Questions

Can an else exist without an if?

No. An else must always be attached to a preceding if that has not already been paired with another else. Java will not compile a standalone else.

Can I have several else blocks on one if?

No. One if can have at most one else. When you need more branches you want an if...else if ladder, which is covered on our if...else if ladder page.

Why does if (count) not compile?

Because Java has no truthy or falsy values. A condition must be strictly a boolean expression, so write if (0 < count) instead. The explicit form also documents your intent for the next reader.

Is the condition evaluated more than once?

No, exactly once. This matters when the condition itself calls a method, because that method runs a single time regardless of what happens inside the branches.

Can I put any statement inside an if block?

Yes, including declarations, assignments, method calls, loops and further if statements. Just remember that a variable declared inside the block will not exist outside it.

Should I use a ternary or an if...else?

Use a ternary when you are only producing a value and the whole thing fits on one readable line. Use if...else when the branches contain several statements, or when the condition is complex enough that inlining it would hurt clarity.