How to Convert Int to String in Java: Methods, Use Cases, and What to Consider

Converting an integer to a string is one of the most common operations in Java programming. Whether you're building a user interface, formatting output, concatenating values, or preparing data for storage, you'll run into this task constantly. Java gives you several ways to do it — and the method you choose can affect readability, performance, and behavior in edge cases.

Why Converting Int to String Matters in Java

Java is a strongly typed language, which means you can't simply treat an integer as a string without an explicit conversion. If you try to pass an int where a String is expected, the compiler will reject it. Understanding the available conversion methods — and when each one applies — is fundamental to writing clean, reliable Java code.

The Main Methods for Converting Int to String in Java

1. String.valueOf(int i)

This is one of the most widely used approaches. The String.valueOf() method accepts a primitive int and returns its string representation.

int number = 42; String result = String.valueOf(number); // result: "42" 

It's clean, readable, and handles the conversion without any intermediate steps. Notably, it also handles the value 0 and negative integers correctly without special handling.

2. Integer.toString(int i)

The Integer wrapper class provides a static toString() method that converts a primitive int directly to a String.

int number = 100; String result = Integer.toString(number); // result: "100" 

This method has an additional overload worth knowing:

String binary = Integer.toString(255, 2); // "11111111" (base 2) String hex = Integer.toString(255, 16); // "ff" (base 16) 

The second argument specifies the radix (base), which makes this method uniquely useful when you need a string representation in binary, octal, or hexadecimal — not just base 10.

3. String Concatenation with ""

A shorthand that many developers use, especially when working quickly:

int number = 7; String result = "" + number; // result: "7" 

This works because Java's + operator, when one operand is a String, converts the other operand to a string automatically. It's concise, but it's worth understanding what's happening under the hood: the compiler often translates this into a StringBuilder operation, which adds a small layer of overhead. In tight loops or performance-sensitive code, this approach can accumulate inefficiency.

4. String.format()

For situations where you need formatted output — padding numbers, adding leading zeros, controlling decimal places — String.format() offers the most control:

int number = 5; String result = String.format("%d", number); // result: "5" String padded = String.format("%05d", number); // result: "00005" 

The %d format specifier is for integer types. This method is more verbose than the others, but it shines when formatting is part of the requirement — such as generating file names, report fields, or display labels. 🎯

5. StringBuilder or StringBuffer

When building strings dynamically from multiple values — especially in loops — using StringBuilder is the standard performant approach:

StringBuilder sb = new StringBuilder(); sb.append(42); String result = sb.toString(); // result: "42" 

StringBuilder is not thread-safe but is preferred for single-threaded contexts. StringBuffer provides thread safety at the cost of some overhead. When concatenating many integers into a single string, StringBuilder is significantly more efficient than repeated + operations.

Comparing the Methods at a Glance

Note on null: These methods accept primitive int values, which cannot be null. If you're working with Integer objects (the wrapper class), null handling becomes a factor — String.valueOf(null) returns the string "null", while calling .toString() on a null Integer object will throw a NullPointerException.

The Variables That Change Which Method Fits

Not every conversion scenario is the same. Several factors shift which approach makes sense:

• Performance context: Inside a loop processing thousands of records, StringBuilder or String.valueOf() outperform repeated concatenation. For a single, one-off conversion, the difference is negligible.
• Output format requirements: If the string needs padding, alignment, or a specific base (binary, hex), Integer.toString(i, radix) or String.format() are the right tools. The others don't offer those options natively.
• Wrapper vs. primitive: If you're working with Integer objects rather than int primitives, you have access to the instance method .toString() directly on the object — but null safety becomes a real consideration.
• Code style and team conventions: Some teams standardize on String.valueOf() for consistency. Others prefer Integer.toString() for its explicit clarity. Both are equally valid from a correctness standpoint.
• Java version: Since Java 8 and beyond, patterns like streams and method references have changed how some developers approach data transformation. In those contexts, you might see Integer::toString used as a method reference. 🔄

Behavior Worth Knowing

One subtle distinction: Integer.toString(int) and String.valueOf(int) produce identical results for primitive integers. However, String.valueOf(Object) — the version that accepts an object — will return the string "null" if passed a null reference. That behavior is intentional and can be useful for safe null handling, but it can also introduce quiet bugs if you're not expecting it.

Negative integers are handled correctly by all methods: String.valueOf(-99) returns "-99" as expected. Zero also converts cleanly — no special cases needed.

When the Choice Isn't Obvious

For most everyday use, String.valueOf() and Integer.toString() are interchangeable and cover the majority of cases cleanly. The decision gets more nuanced when you factor in your specific data pipeline — whether you're working in a single-threaded environment, whether output formatting is baked into requirements, and whether you're processing primitives or objects throughout the codebase.

The conversion method that works cleanly in a simple utility class may not be the right fit inside a multi-threaded data processing pipeline or a formatting-heavy reporting module — and that gap between general guidance and your specific setup is the piece only your own code context can fill.