Programmatic text comparisons

Compare JavaScript Text with an Explicit Equality Rule

Compare JavaScript Text with an Explicit Equality Rule. Apply explicit data rules and checked examples while preserving the original inputs.

By Uddhav Gopani, FounderPublished 27 September 2026Updated 29 September 2026

For two JavaScript string values, strict equality tests whether they contain the same stored sequence in the same order. It does not ignore case, spaces or Unicode normalization differences. Choose whether you need that exact identity or a deliberately normalized comparison before writing the condition.

Check exact and normalized equality separately

const original = "e\u0301";
const revised = "é";
console.log(original === revised); // false: different stored sequences
console.log(original.normalize("NFC") === revised.normalize("NFC")); // true
console.log("Alpha" === "alpha"); // false: case-sensitive
console.log("00123" === "123"); // false: distinct string identifiers

The first string contains e followed by a combining acute accent, while the second contains a precomposed accented character. They look similar but are different sequences. NFC normalization makes these two canonically equivalent forms agree. The case and identifier examples remain distinct under ordinary strict equality.

Validate that the inputs are strings

Use string values deliberately rather than relying on loose equality to convert other types. The string 1 and the number 1 are different values under strict equality. If a form or API supplies an unexpected object or missing value, decide how to handle that state instead of automatically converting everything into a display string.

An empty string is a valid string value and can equal another empty string. That does not necessarily mean an empty form submission is valid for the application. Input validation and equality testing answer separate questions; enforce a required nonempty field at the appropriate application boundary.

Apply only the transformations the task needs

Trimming outer whitespace can be appropriate for a lookup key but inappropriate for exact source text. Removing all spaces can turn ab c and a bc into the same value even though their word boundaries differ. Keep the original strings and label any normalized equality result with the rule that produced it.

Case-insensitive matching also requires a policy, especially for language-sensitive text. Do not assume that a lowercase transformation is a universal linguistic equivalence test. For an exact identifier, case may be significant and should remain visible.

Use a diff when false is not enough

A Boolean false tells you that the chosen comparison found a difference; it does not show where or why. For a review interface, use a line or word diff with clearly labeled original and revised sources. A missing negative word or changed digit can matter even when most of the text agrees.

The local Text Diff Checker normalizes its supplied text to NFC. It can therefore report a match for the first accented pair even though the raw JavaScript strict-equality expression returns false. Those results concern different identity rules rather than proving that one operation is broken.

Keep representative acceptance cases

Test identical ordinary text, a changed word, a case-only change, a leading-zero identifier and a Unicode normalization pair. Add a second input after the first test so an old result cannot be mistaken for a new comparison. Keep expected outcomes in the test instead of accepting any Boolean return as a successful check.

Do not compare source code by executing it, and do not insert an untrusted text value into HTML merely to show the result. Display the text as text. Equality and diff operations do not require running scripts contained in the input.

Keep exactness separate from meaning

Two differently worded sentences can express similar ideas, while a one-character change can alter an amount substantially. String equality does not judge semantic equivalence, correctness, authorship or plagiarism. Use the Boolean result for the specific text-identity question it answers.

Handle missing input before normalization

A missing value is not an empty string. Calling a string method on null or undefined is an input error, so validate the expected type before normalizing. Do not replace a missing required source with an empty value and then report that two empty inputs prove the intended documents match.

JavaScript reference

MDN’s strict-equality reference documents the operator. The four printed outcomes above are independently executed examples.