Introduction

String.equals and String.contentEquals both compare character content, but they are designed for slightly different input types. If you are comparing one String to another, equals is usually the normal choice; contentEquals becomes useful when the other value is a CharSequence or StringBuffer rather than a plain String.

Core Sections

What String.equals does

equals overrides Object.equals and checks whether the other object is also a String with the same sequence of characters.

1String a = "hello";
2String b = new String("hello");
3String c = "world";
4
5System.out.println(a.equals(b));
6System.out.println(a.equals(c));

This is the standard API for string-to-string equality in Java. It is what most Java readers expect when they see a direct comparison between two String values.

What contentEquals does

contentEquals compares the characters of the String against another text-like object. The key difference is that it accepts CharSequence and StringBuffer rather than just String.

1String text = "hello";
2StringBuilder builder = new StringBuilder("hello");
3CharSequence sequence = "hello";
4
5System.out.println(text.contentEquals(builder));
6System.out.println(text.contentEquals(sequence));

This is useful when you already have a mutable or abstract character container and do not want to convert it to a new String just to compare content. That matters in parser code, builders, and adapter layers where converting every intermediate CharSequence into a standalone String would add clutter and sometimes unnecessary allocation.

When the methods return the same result

If both sides are ordinary String instances, equals and contentEquals typically tell you the same truth value.

1String x = "abc";
2String y = "abc";
3
4System.out.println(x.equals(y));
5System.out.println(x.contentEquals(y));

In that case, equals is usually preferable because it is the more direct and conventional API. It also tells the next reader that both operands are expected to be actual String objects, not just arbitrary character containers that happen to expose similar content.

When contentEquals is the better fit

Suppose an API gives you a StringBuilder, StringBuffer, or generic CharSequence. Using contentEquals avoids an unnecessary conversion.

1String expected = "status=ok";
2StringBuffer actual = new StringBuffer("status=ok");
3
4if (expected.contentEquals(actual)) {
5    System.out.println("match");
6}

If you used equals here, the result would be false because the argument is not a String even though the visible characters match.

Do not confuse content comparison with reference comparison

Neither method cares whether the two objects are the same instance in memory. They compare characters, not references. That is why == is the wrong tool when you mean textual equality.

1String s1 = new String("java");
2String s2 = new String("java");
3
4System.out.println(s1 == s2);      // false
5System.out.println(s1.equals(s2)); // true

That distinction is more fundamental than the difference between equals and contentEquals.

Common Pitfalls

• Using == for text comparison and then trying to reason about equals and contentEquals on top of the wrong baseline.
• Calling equals with a StringBuilder or StringBuffer and expecting character equality instead of type-sensitive object equality.
• Using contentEquals everywhere even when both sides are clearly String, which makes the code less idiomatic than necessary.
• Forgetting that contentEquals is useful precisely because some APIs expose CharSequence rather than concrete String values.
• Treating the methods as fundamentally different comparison algorithms when the real difference is mostly in accepted argument types and intended use.

Summary

• 'String.equals is the normal choice when comparing one String to another.'
• 'String.contentEquals is useful when comparing a String to CharSequence or StringBuffer content.'
• If both operands are String, the two methods usually produce the same answer.
• 'equals is more idiomatic for string-to-string comparison.'
• The larger comparison mistake to avoid is using == when you really want content equality.