Java String Comparison

Java String Comparison

String comparison is one of those topics that looks trivial until it silently breaks production code. A login system that uses == instead of equals() lets every user in — or lets no one in. A report sorted with the wrong comparator mixes "Apple" and "apple" incorrectly. A null check done in the wrong order throws NullPointerException during a critical payment flow.

Java gives you several ways to compare strings. Each one answers a different question — same object in memory, same content, same content ignoring case, or which string comes first alphabetically. Knowing which question you actually need answered determines which method to use.

The Four Questions String Comparison Answers

Question 1: Do both variables point to the SAME object in memory?
  → Use ==

Question 2: Do both strings contain exactly the SAME characters?
  → Use equals()

Question 3: Do both strings have the same characters, regardless of case?
  → Use equalsIgnoreCase()

Question 4: Which string comes first in alphabetical (dictionary) order?
  → Use compareTo() or compareToIgnoreCase()

These four questions cover every legitimate string comparison scenario. Picking the wrong one produces either a silent bug (wrong result, no exception) or a runtime crash.

1 — == Operator: Reference Comparison

== on objects checks whether two variables point to the same memory address — the same object instance. It does not check content. Two different String objects that contain identical text return false with ==.

Output:
=== String Pool (literals) ===
a == b : true
a == c : false

=== Heap Objects (new keyword) ===
a == x : false
x == y : false
x == x : true

=== Identity Hash Codes ===
a hashCode: 1829164700
b hashCode: 1829164700
x hashCode: 2018699554
y hashCode: 1311053135

a and b share the same identity hash code — they are literally the same object, which is why == returns true. x and y each have a unique address — they are separate objects even though their content is identical.

Memory layout:

String Pool:
  ┌─────────────┐
  │  "hello"    │ ◄── a  and  b  both point here
  └─────────────┘
  ┌─────────────┐
  │  "world"    │ ◄── c
  └─────────────┘

Heap (normal area):
  ┌─────────────┐   ┌─────────────┐
  │  "hello"    │   │  "hello"    │
  └─────────────┘   └─────────────┘
        ▲                   ▲
        x                   y

When == is appropriate for Strings: Almost never for content comparison. The only legitimate use is checking whether a string is literally the same object as another known reference — which is unusual in application code.

2 — equals(): Content Comparison

equals() compares the actual character content of two strings. It returns true when both strings contain the same sequence of characters in the same case, regardless of whether they are the same object in memory.

Output:
=== equals() ===
s1.equals(s2) : true
s1.equals(s3) : false
s1 == s2      : false

=== Null Safety ===
"admin".equals(null) : false
"admin".equals("")   : false
"admin".equals("admin"): true

=== Password Check ===
  'secret@123'    → DENIED
  'Secret@123'    → GRANTED
  'SECRET@123'    → DENIED
  ''              → DENIED
  'null'          → DENIED

The constant-on-left pattern — "knownValue".equals(variable) — is the single most important habit for String comparison. When variable is null, calling variable.equals("known") crashes with NullPointerException. Calling "known".equals(variable) safely returns false.

3 — equalsIgnoreCase(): Case-Insensitive Comparison

equalsIgnoreCase() compares content while treating uppercase and lowercase letters as identical. Useful for username lookups, search, role checking, city names, and any input where the caller's capitalisation should not matter.

Output:
=== equalsIgnoreCase() ===
stored: bengaluru
  Bengaluru    → true
  BENGALURU    → true
  BenGaLuRu    → true
  Mumbai       → false

=== Product Search: 'laptop stand' ===
  Found: Laptop Stand

=== Role Check: MANAGER ===
  Reports and team access granted.

=== Difference between equals and equalsIgnoreCase ===
equals()          : false
equalsIgnoreCase(): true

4 — compareTo() and compareToIgnoreCase()

compareTo() returns an integer — not a boolean. Zero means equal. A negative number means the calling string comes before the argument alphabetically. A positive number means it comes after. This is used for sorting.

Output:
=== compareTo() ===
'Apple'.compareTo('Banana') : -1
'Banana'.compareTo('Apple') : 1
'Apple'.compareTo('Apple')  : 0
'Apple'.compareTo('Cherry') : -2

=== compareTo() with case ===
'APPLE'.compareTo('apple') : -32
compareToIgnoreCase         : 0

=== Sorting Cities ===
Before sort: [Pune, Delhi, Bengaluru, Mumbai, Chennai, Hyderabad]
After sort : [Bengaluru, Chennai, Delhi, Hyderabad, Mumbai, Pune]

Sorted (longer first): [Deepak, Ananya, Rohan, Priya, Sneha, Karan]

Case-insensitive sort: [Apple, banana, cherry, DATE, elderberry]

compareTo() uses Unicode values. Uppercase letters ('A' = 65) come before lowercase ('a' = 97), so "APPLE".compareTo("apple") returns a negative value. Use compareToIgnoreCase() when case should not affect sort order.

5 — String Pool and How It Affects ==

Understanding the String pool explains why == sometimes returns true for strings that are "different" variables — and why relying on this is dangerous.

Output:
=== Compile-time Constants ===
a == b : true
a == c : false

=== intern() ===
a == d       : false
a == e       : true
a.equals(d)  : true

=== Why == Fails in Practice ===
Wrong (==)    : false
Correct (equals): true

Strings from user input, file reading, database queries, and API responses are always heap objects — never from the pool. Using == to check such strings almost always returns false even when the content is identical. This is the bug that makes == vs equals() such a critical interview topic.

equals() vs == vs equalsIgnoreCase() vs compareTo() — Comparison Table

Null-Safe String Comparison

Null is one of the most common sources of NullPointerException in Java. All String comparison methods throw NPE when called on a null reference. There are several patterns to handle this safely.

Output:
=== Pattern 1: Constant on Left ===
false
false
false

=== Pattern 2: Explicit Null Check ===
No match (null or different)

=== Pattern 3: Objects.equals() ===
true
false
true
true

=== Pattern 4: String.valueOf() ===
safe equals 'null': true
safe value: 'null'

=== Null / Empty / Blank Classification ===
  'null'     → NULL
  ''         → EMPTY
  '   '      → BLANK (whitespace)
  'hello'    → HAS CONTENT

Objects.equals(a, b) is the cleanest null-safe comparison for both sides. It handles: both null → true, one null → false, both non-null → delegates to a.equals(b).

Basic Example

Output

a == c             : false
a.equals(b)        : false
a.equalsIgnoreCase : true
a.compareTo(b)     : 32

How it works:

1. ›a == c is false because c was created with new String(...), making it a separate object from the pooled literal a, even though the text matches.
2. ›a.equals(b) is false because equals() is case-sensitive, and "apple" does not exactly match "Apple".
3. ›a.equalsIgnoreCase(b) is true because it treats 'a' and 'A' as the same letter.
4. ›a.compareTo(b) returns 32 — a positive number — because lowercase 'a' (Unicode 97) comes after uppercase 'A' (Unicode 65) in the character set.

Best Practices

Always use equals() for String content comparison — never ==. Use == only when you intentionally need to check whether two references point to the same object, which is rare in application code. For all content comparisons — login checks, search, validation — equals() is the correct tool.

Put the known non-null constant on the left side of equals(). Writing "expectedValue".equals(userInput) means the comparison safely returns false even when userInput is null. Writing userInput.equals("expectedValue") crashes with NullPointerException when userInput is null.

Use Objects.equals(a, b) when both sides might be null. This utility method from java.util.Objects handles all null combinations without any explicit null check — both null returns true, one null returns false, both non-null delegates to a.equals(b).

Use equalsIgnoreCase() when the caller's capitalisation should not matter. City names, product categories, role names, search queries, and user-supplied codes are all cases where the caller may type in any case. equalsIgnoreCase() handles all variations without requiring toLowerCase() on both sides.

Common Mistakes

Mistake 1 — Using == for Content Comparison

This bug is hard to spot because it sometimes works — when both strings happen to be literals from the pool. It breaks when strings come from user input, files, or databases.

Mistake 2 — NPE From Calling equals() on a Possibly-Null Variable

Mistake 3 — Using equals() Instead of equalsIgnoreCase() for User Input

Mistake 4 — Misreading compareTo() Return Value

compareTo() does not guarantee returning exactly 1 or -1. It returns any positive or negative number. Always use > 0, < 0, and == 0 — never == 1 or == -1.

Interview Questions

Q1. What is the difference between == and equals() for String comparison in Java?

== compares references — it checks whether two variables point to the same object in memory. equals() compares content — it checks whether two strings contain the same sequence of characters. Two different String objects with identical content return false for == but true for equals(). For string content comparison, always use equals(). The == operator should never be used to compare String content in production code.

Q2. Why does == sometimes return true for two different String variables?

Because of the String pool. When Java encounters a string literal like "hello", it checks the pool first. If "hello" already exists there, it reuses the same object rather than creating a new one. Two variables both assigned the literal "hello" end up pointing to the same pooled object, so == returns true. This only works for compile-time literals. Strings from user input, files, databases, and API calls are always heap objects — == will return false for them even if the content matches.

Q3. What is the safest pattern to compare a String when the variable might be null?

Three safe patterns: first, put the known non-null string on the left — "expected".equals(variable) returns false safely if variable is null. Second, use Objects.equals(a, b) from java.util.Objects — this handles both sides being null and returns true when both are null. Third, explicitly check for null before comparing — if (variable != null && variable.equals("expected")). The constant-on-left pattern is the most commonly adopted in Java production code.

Q4. What does compareTo() return and how should you use the result?

compareTo() returns an int. Zero means the strings are equal. A negative integer means the calling string comes before the argument alphabetically. A positive integer means it comes after. The actual magnitude varies — it does not always return 1 or -1. Always use > 0, < 0, and == 0 to interpret the result, never compare it to a specific number. compareTo() is used for sorting and ordering — whenever you need to determine relative alphabetical position rather than simple equality.

Q5. When should you use equalsIgnoreCase() instead of equals()?

Use equalsIgnoreCase() whenever the caller's capitalisation should not affect the comparison result — city names, role names, status codes, search queries, product categories, and user-supplied identifiers. For security-sensitive comparisons like passwords, use equals() — case matters there. For API responses or database values with a controlled format, equals() is appropriate. The general rule: if you would normalise both strings to the same case before comparing, use equalsIgnoreCase() directly — it is cleaner and avoids creating two temporary lowercase strings.

Q6. What is the difference between Objects.equals() and String.equals()?

String.equals() is an instance method — calling it on a null reference throws NullPointerException. Objects.equals(a, b) is a static utility method from java.util.Objects that handles null on both sides: if both are null, it returns true; if one is null, it returns false; if neither is null, it delegates to a.equals(b). Use Objects.equals() when either value might be null and you do not want to write a null check manually. Use String.equals() when you know the left side is non-null.

FAQs

Is String comparison in Java case-sensitive by default?

Yes. equals(), compareTo(), contains(), startsWith(), endsWith(), and indexOf() are all case-sensitive. Comparing "Admin" to "admin" with equals() returns false. Use equalsIgnoreCase() or compareToIgnoreCase() when you need case-insensitive comparison, or normalise both strings to lowercase first with toLowerCase().

Why is "hello" == "hello" true but new String("hello") == new String("hello") false?

String literals are stored in the String pool and reused. Both "hello" literals resolve to the same pooled object, so their references are equal. new String("hello") creates a new object in heap memory every time, bypassing the pool. Each call produces a separate object with a different address, so == returns false. This is why == for Strings is unreliable — its result depends on how the strings were created, not on their content.

Can you use compareTo() to check equality instead of equals()?

Technically yes — a.compareTo(b) == 0 is true when the strings are equal. But it is not recommended. equals() is more readable, more clearly communicates intent, and handles the comparison at the conceptual level of "same content". compareTo() communicates ordering. Using compareTo() for equality checks confuses readers who will wonder why sorting logic appears where equality is expected.

Does equalsIgnoreCase() work with all languages and Unicode characters?

For ASCII characters (A-Z, a-z), equalsIgnoreCase() works correctly and consistently. For Unicode characters beyond ASCII — accented letters, Cyrillic, etc. — Java's case folding may not match the full Unicode case-mapping rules in all locales. For locale-sensitive comparison, use java.text.Collator which applies locale-specific rules. For most Indian language text stored as Unicode, simple equalsIgnoreCase() works correctly.

What happens when you call compareTo() on a null string?

Calling "hello".compareTo(null) throws NullPointerException. The compareTo() method does not handle null arguments. If either string might be null, check for null before calling compareTo(), or use java.util.Comparator.nullsFirst() or nullsLast() when sorting with null-tolerant ordering.

Summary

String comparison in Java has four tools and four distinct purposes. == for reference identity — rarely the right choice for strings. equals() for exact content match — the default for most comparisons. equalsIgnoreCase() for content match when capitalisation is irrelevant — user input, roles, categories. compareTo() for ordering — sorting, finding the earliest or latest in a sequence.

The two habits that prevent most comparison bugs: always use equals() instead of ==, and always put the known non-null value on the left side of equals(). Add Objects.equals() for cases where both sides might be null, and equalsIgnoreCase() for user-supplied strings where case should not matter.

What to Read Next