Introduction

Converting a long to an int in Java is easy syntactically but dangerous if the value might be out of range. Java allows the narrowing conversion with a cast, but it does not automatically protect you from overflow.

The Basic Cast

The direct syntax is an explicit cast.

1public class Main {
2    public static void main(String[] args) {
3        long value = 123L;
4        int result = (int) value;
5        System.out.println(result);
6    }
7}

This works correctly when the long value is already within the valid int range.

The valid range for int is:

• '-2147483648'
• '2147483647'

If the source value is outside that interval, the cast still compiles and runs, but the numeric result wraps.

Why a Plain Cast Can Be Wrong

A cast from long to int discards the upper 32 bits. That means the result can look unrelated to the original number if the original number is too large or too small.

1public class Main {
2    public static void main(String[] args) {
3        long value = 3000000000L;
4        int result = (int) value;
5        System.out.println(result);
6    }
7}

This does not throw an exception. It produces a wrapped value because Java treats the conversion as a low-level narrowing operation.

That is why the real question is not “How do I convert it?” but “What should happen if it does not fit?”

Use Math.toIntExact for Safe Conversion

If overflow should be treated as an error, the best built-in option is Math.toIntExact.

1public class Main {
2    public static void main(String[] args) {
3        long value = 123L;
4        int result = Math.toIntExact(value);
5        System.out.println(result);
6    }
7}

For an out-of-range value, it throws ArithmeticException.

1public class Main {
2    public static void main(String[] args) {
3        long value = 3000000000L;
4        int result = Math.toIntExact(value);
5        System.out.println(result);
6    }
7}

This is usually the safest choice in business logic because it fails fast instead of silently corrupting the value.

Manual Range Checking

If you want a custom error message or special handling, check the range yourself before casting.

1public class Main {
2    public static void main(String[] args) {
3        long value = 3000000000L;
4
5        if (value < Integer.MIN_VALUE || value > Integer.MAX_VALUE) {
6            throw new IllegalArgumentException("Value out of int range: " + value);
7        }
8
9        int result = (int) value;
10        System.out.println(result);
11    }
12}

This gives you full control over the failure behavior.

Clamping as a Policy Choice

Some systems do not want an exception. They want the value limited to the nearest valid bound.

1public class Main {
2    public static void main(String[] args) {
3        long value = 3000000000L;
4        int result;
5
6        if (value > Integer.MAX_VALUE) {
7            result = Integer.MAX_VALUE;
8        } else if (value < Integer.MIN_VALUE) {
9            result = Integer.MIN_VALUE;
10        } else {
11            result = (int) value;
12        }
13
14        System.out.println(result);
15    }
16}

This is not a normal numeric conversion. It is a deliberate application rule. Use it only when saturation behavior actually makes sense for the domain.

Choose the Right Approach for the Problem

A simple way to decide is:

• use (int) value when you already know the range is safe
• use Math.toIntExact(value) when overflow should be rejected
• use manual checks when you need a custom response
• use clamping only when the domain explicitly wants it

For example, a database ID that logically should never exceed int often deserves Math.toIntExact. A UI slider limit might reasonably use clamping.

When Conversion Is the Wrong Design

Sometimes the presence of a long is already telling you something important: the value may not belong in an int at all. File sizes, timestamps, counters, and offsets often use long precisely because they can exceed int safely.

If you are converting only because another API accepts int, stop and ask whether that API boundary is the right place for narrowing. The cast may be legal while the design is still wrong.

Wrapper Types and Auto-Unboxing

The same range concerns apply when working with wrapper classes.

Long boxed = 500L;
int result = Math.toIntExact(boxed);
System.out.println(result);

If boxed is null, this throws NullPointerException during unboxing. So when wrappers are involved, you must think about both range and nullability.

Common Pitfalls

A common mistake is assuming Java throws an exception on overflow during a cast. It does not.

Another mistake is narrowing a value simply to satisfy an API without checking whether the source can exceed the target range.

Developers also sometimes clamp values silently when the correct behavior should have been to reject bad input. That can hide serious bugs.

Finally, wrapper types add another hazard: a Long can also be null, so the conversion problem may be both numeric and nullable.

Summary

• Cast with (int) when the value is known to fit.
• Use Math.toIntExact when overflow should throw an exception.
• Add manual checks when you need custom behavior.
• Clamp only when saturation is a real business rule.
• Before converting, ask whether int is actually the correct type for the value.