Validate Number in Range in Java: Inclusive vs Exclusive (2026)

Introduction

Validating whether a number falls within a range sounds almost too simple to dedicate an entire guide to — until you realize how many real bugs stem from getting the boundary conditions wrong. Should the range include its endpoints or not? Is age 18 considered "within" an 18-65 range, or does the range start at 19?

This single question — inclusive versus exclusive boundaries — is exactly the kind of detail that separates correct validation logic from subtly broken code that fails on edge cases.

This guide covers both inclusive and exclusive range validation, taking real user input via Scanner, validating against multiple possible ranges simultaneously, and a genuinely practical example modeling age and percentage validation — precisely the kind of range-checking logic found throughout real-world form validation and QA automation testing.

Inclusive vs Exclusive Range: Why This Distinction Matters

An inclusive range includes both its boundary values as valid — for example, "between 1 and 10, inclusive" means both 1 and 10 themselves count as valid.

An exclusive range excludes one or both boundaries — "between 1 and 10, exclusive" might mean only values strictly greater than 1 and strictly less than 10 qualify (2 through 9).

Real-world specifications are often ambiguous about which is intended ("ages 18 to 65" — does 65 itself qualify?), making this the single most important clarifying question to ask before implementing any range-validation logic.

Method 1: Basic Inclusive Range Check

This is the standard implementation when both boundary values should be considered valid.

public class ValidateRangeInclusive {
    public static void main(String[] args) {
        int num = 10;
        int min = 1;
        int max = 10;

        boolean isValid = num >= min && num <= max;

        System.out.println(num + " is " +
                (isValid ? "within" : "outside") +
                " the range [" + min + ", " + max + "].");
    }
}

How this works

num >= min && num <= max requires the number to be greater than or equal to the lower bound and less than or equal to the upper bound — using >= and <= (rather than strict > and <) is precisely what makes both boundary values count as valid.

Output

10 is within the range [1, 10].

Method 2: Exclusive Range Check

When boundaries should specifically be excluded, switch to strict relational operators.

public class ValidateRangeExclusive {
    public static void main(String[] args) {
        int num = 10;
        int min = 1;
        int max = 10;

        boolean isValid = num > min && num < max;

        System.out.println(num + " is " +
                (isValid ? "within" : "outside") +
                " the exclusive range (" + min + ", " + max + ").");
    }
}

Output

10 is outside the exclusive range (1, 10).

Notice the exact same input (num = 10) produces a genuinely different, opposite result depending purely on whether the range is inclusive or exclusive — a vivid demonstration of why this distinction absolutely must be clarified and correctly implemented rather than assumed.

Method 3: Validating User Input with Scanner

For an interactive, genuinely useful validator:

import java.util.Scanner;

public class ValidateRangeScanner {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int min = 1, max = 100;

        System.out.print("Enter a number between " + min + " and " + max + " (inclusive): ");
        int num = sc.nextInt();

        if (num >= min && num <= max) {
            System.out.println(num + " is valid.");
        } else {
            System.out.println(num + " is invalid. Please enter a number between " + min + " and " + max + ".");
        }

        sc.close();
    }
}

Sample interaction

Enter a number between 1 and 100 (inclusive): 150
150 is invalid. Please enter a number between 1 and 100.

This is exactly the kind of validation loop you'd build into a real console application, clearly communicating both the valid range and the specific reason for rejection when input falls outside it.

Method 4: Validating Against Multiple Ranges

Some real-world scenarios require checking whether a number falls into any one of several valid ranges — for example, a grading system with distinct score bands.

public class ValidateMultipleRanges {

    static boolean isInAnyRange(int num, int[][] ranges) {
        for (int[] range : ranges) {
            if (num >= range[0] && num <= range[1]) {
                return true;
            }
        }
        return false;
    }

    public static void main(String[] args) {
        int[][] validRanges = {
                {1, 10},
                {50, 60},
                {90, 100}
        };

        int num = 55;

        System.out.println(
                num + " is " +
                (isInAnyRange(num, validRanges) ? "valid" : "invalid") +
                ".");
    }
}

Output

55 is valid.

How this works

validRanges is a 2D array, where each inner array represents one {min, max} pair.

The isInAnyRange() method loops through each range, checking whether the number falls within it, returning true immediately (short-circuiting further checks) the moment any single range matches.

A Practical Example: Age and Percentage Validation

Bringing this together into genuinely realistic validation logic:

public class AgeAndPercentageValidator {

    static boolean isValidAge(int age) {
        return age >= 0 && age <= 120;
    }

    static boolean isValidPercentage(double percentage) {
        return percentage >= 0.0 && percentage <= 100.0;
    }

    public static void main(String[] args) {
        int age = 25;
        double percentage = 87.5;

        System.out.println("Age " + age + " valid: " + isValidAge(age));
        System.out.println("Percentage " + percentage + " valid: " + isValidPercentage(percentage));

        System.out.println("Age -5 valid: " + isValidAge(-5));
        System.out.println("Percentage 105.0 valid: " + isValidPercentage(105.0));
    }
}

Output

Age 25 valid: true
Percentage 87.5 valid: true
Age -5 valid: false
Percentage 105.0 valid: false

This mirrors exactly the kind of input-validation logic that appears throughout real form-processing code, API request validation, and automated test scripts checking boundary conditions on numeric fields.

How Java Handles This Internally (Memory Concept)

• All numeric variables (num, min, max, age, percentage) are primitive values (int or double) stored in stack memory, with range checks performed as simple relational comparisons at the CPU level.
• In Method 4, the int[][] validRanges is a heap-allocated two-dimensional array, with each inner int[] array itself also heap-allocated, and the loop iterating through the outer array's references to check each inner range.
• Java's logical AND operator (&&) uses short-circuit evaluation — if num >= min is already false, Java doesn't bother evaluating num <= max at all, since the overall result is already determined.

Real-Life Analogy: A Bouncer Checking an Age Requirement

Imagine a nightclub bouncer checking IDs against an age requirement: "must be 21 or older" is an inclusive lower boundary — turning 21 today means you qualify immediately, not just from 22 onward.

But a different venue's rule, "under 18s only" for a teen event, is an exclusive upper boundary — someone who is exactly 18 would not qualify, since the rule specifically means "younger than 18," not "18 or younger."

This precise, careful reading of whether a boundary is included or excluded is exactly the distinction range-validation code must get right — and just like a careless bouncer might incorrectly admit or reject someone right at the boundary age, careless code can silently accept or reject values right at the range's edges.

Comparison Table of All Methods

Best Practices

• Always explicitly clarify whether a range should be inclusive or exclusive before implementing validation logic — never assume, since real-world specifications are frequently ambiguous on this exact point.
• Use >= and <= for inclusive boundaries, and strict >/< for exclusive ones — this single operator choice is the entire difference between the two behaviors.
• Test your validation logic specifically at the boundary values themselves (not just comfortably inside or outside the range), since boundary conditions are exactly where off-by-one bugs hide.
• For multiple range validation, structure your valid ranges as a clear, well-organized data structure (like a 2D array or a list of small range objects) rather than a long chain of separate OR conditions.
• Provide clear, specific error messages when validation fails, ideally restating the valid range, to help users or downstream systems understand exactly what went wrong.

Common Mistakes Beginners Make

• Using the wrong relational operators for the intended inclusive/exclusive behavior, such as using strict < and > when the boundaries should actually be included.
• Not testing boundary values explicitly, missing off-by-one bugs that only manifest exactly at the range's edges rather than well within or outside it.
• Assuming a range's inclusivity without confirming it, implementing logic based on an incorrect assumption about whether "18 to 65" includes 65 itself.
• Hardcoding range checks repeatedly throughout a codebase instead of extracting a reusable, well-named validation method that clearly documents its inclusive/exclusive behavior.
• Forgetting to handle multiple valid ranges correctly, mistakenly requiring a number to satisfy all ranges simultaneously (using AND) instead of any one of them (using OR or a loop with early return).

Expert Tips for Interviews

A strong, well-rounded interview answer sounds like this:

"Before implementing a range check, I always clarify whether the boundaries themselves should be considered valid — an inclusive range uses greater-than-or-equal-to and less-than-or-equal-to, while an exclusive range uses strict greater-than and less-than. I make sure to test boundary values explicitly, since off-by-one errors specifically hide at the range's edges. If validating against multiple possible ranges, I'd structure them as a clear data structure and loop through them, returning true the moment any single range matches, rather than requiring all of them to match simultaneously."

Proactively raising the inclusive-versus-exclusive clarifying question, rather than silently assuming one or the other, is exactly the kind of careful requirements-gathering instinct that distinguishes a strong engineer from someone who codes first and asks questions later.

Pros and Cons

Inclusive Range Check

Pros

• ✅ Matches the most common real-world interpretation of ranges

Cons

• ❌ Must be explicitly confirmed as the correct interpretation for your specific use case

Exclusive Range Check

Pros

• ✅ Correctly handles scenarios explicitly excluding boundaries

Cons

• ❌ Easy to accidentally apply when inclusive behavior was actually intended

Multiple Range Validation

Pros

• ✅ Cleanly handles complex, tiered validation requirements

Cons

• ❌ Requires careful data structure design to remain readable and maintainable

Frequently Asked Questions (FAQs)

1. How do I check if a number is within a range in Java?

Use num >= min && num <= max for an inclusive range (where both boundaries count as valid), or num > min && num < max for an exclusive range (where boundaries are excluded).

2. What is the difference between an inclusive and exclusive range?

An inclusive range counts its boundary values as valid, while an exclusive range excludes one or both boundaries — the same input number can be considered valid or invalid depending entirely on which interpretation applies.

3. How do I validate user input against a range using Scanner?

Read the input with sc.nextInt() (or nextDouble() for decimals), then apply your inclusive or exclusive range check, providing clear feedback if the input falls outside the valid range.

4. How do I validate a number against multiple possible ranges?

Store the valid ranges in a data structure (like a 2D array), then loop through each one, checking if the number falls within it, returning true as soon as any single range matches.

5. Why is it important to test boundary values specifically?

Because off-by-one errors — using the wrong relational operator for inclusive versus exclusive logic — specifically manifest at the range's exact edges, not in values comfortably inside or outside the range.

6. How do I validate an age or percentage value in Java?

Use an inclusive range check appropriate to the value's meaningful bounds — for example, age >= 0 && age <= 120 for age, or percentage >= 0.0 && percentage <= 100.0 for a percentage.

7. What is the time complexity of a single range check?

O(1) — it involves just two simple relational comparisons regardless of the number's value.

8. What is the time complexity of validating against multiple ranges?

O(k), where k is the number of ranges being checked, since each range requires its own comparison in the worst case (if no early match is found).

9. Should I use int or double for range validation?

Use int for whole-number ranges (like age) and double for ranges that might involve decimal values (like percentages or measurements) — matching your data type to the actual nature of the values being validated.

10. Is range validation a common QA automation or testing topic?

Yes, extremely common — boundary value analysis (testing values at, just inside, and just outside a valid range) is a fundamental, widely taught software testing technique specifically designed to catch these exact kinds of off-by-one bugs.

11. How do I provide a helpful error message when validation fails?

Include the specific valid range in your error message (e.g., "must be between 1 and 100"), helping the user or calling system understand exactly what input would have been acceptable.

12. Can range validation logic be reused across a larger application?

Yes, and it should be — extracting a well-named, clearly documented validation method (like isValidAge() or isInRange()) avoids duplicating the same inclusive/exclusive logic and potential bugs across multiple parts of a codebase.