char vs String in Java

A char is a primitive: a single unsigned 16-bit UTF-16 code unit, stored inline, comparable with ==, and never null. A String is a class: an object holding a sequence of characters, compared by value with equals, and possibly null.

The comparison semantics are the part that trips people up. char is a primitive, so c1 == c2 compares the two values directly and does exactly what you expect. A String is a reference, so s1 == s2 compares identity, and only tells you whether the two variables point at the same object. Two Strings holding the same letters are usually different objects, so == says false.

Where you reach for a char: a single character from user input, a loop variable over a short alphabet, a code point in a switch, a flag. Where you reach for a String: anything that is text rather than a symbol — a name, a line, a key. A String of length one is still a String, and using it where a char is expected requires a charAt call.

One wrinkle: Java's char is a UTF-16 code unit, not a full character. Any character outside the Basic Multilingual Plane — most emoji, some historic scripts, some musical symbols — is stored as a surrogate pair of two chars. So a char cannot represent every character a user might type, and code that counts characters with a char counter will undercount. Where that matters, use codePointCount or the code-point APIs.

Because char is a primitive value and String is an object reference. Comparing two chars compares two 16-bit values. Comparing two String references compares two addresses, and only answers the question "are these the same object?" — which for strings is a question about the constant pool, not about the text.

public class Main {
    public static void main(String[] args) {
        char a = 'x';
        char b = 'x';
        System.out.println("char == char    : " + (a == b));      // value comparison

        String s1 = "x";
        String s2 = "x";
        System.out.println("String == String: " + (s1 == s2));    // reference comparison
        System.out.println("String equals   : " + s1.equals(s2));

        // charAt returns a char, so == is fine here.
        System.out.println("charAt ==       : " + ("java".charAt(0) == 'j'));

        // Characters outside the BMP need a surrogate pair.
        String euro = "\u20AC";
        System.out.println("euro length     : " + euro.length());
        System.out.println("euro code point : " + (int) euro.codePointAt(0));

        // An emoji is two chars but one code point.
        String emoji = "\uD83D\uDE00";
        System.out.println("emoji chars     : " + emoji.length());
        System.out.println("emoji points    : " + emoji.codePointCount(0, emoji.length()));
    }
}

Reading the output: the two chars compare equal, the two Strings are reference-equal only because both came from the same pool entry, and equals gives the value answer you actually wanted. The last two lines show the surrogate problem in numbers — the euro sign is one char and one code point, while the emoji occupies two chars but is still a single code point.

So the guidance is: use == for chars, and equals for Strings, without exception. There is one narrow case where == on Strings is legitimate — when you are deliberately checking whether two references point at the same pooled instance, which is occasionally useful when reasoning about interning. It is never the right tool for a value comparison, and the habit of writing it anyway is the origin of a whole family of production bugs where the code works on literals and fails on values loaded from a database or a request.