Check If Text Contains a Substring and Find Its Position

It returns a boolean result and the zero-based position of the first match, or -1 when no match exists. You can preserve exact letter casing or ignore uppercase and lowercase differences. The result is deterministic, easy to test, and useful anywhere a workflow needs a quick search condition without regular expressions or fuzzy matching.

Check a substring with an unambiguous result

Provide the complete value in text and the sequence you want to locate in substring. The response includes contains, which is true when a match exists, and position, which identifies where the first match begins. Positions are zero-based, so a substring found at the very beginning has position 0. A missing substring produces false and position -1, keeping absence distinct from a match at the start. This pairing makes the result convenient for people reading it and for software applying a condition. The operation looks for a literal, contiguous substring. Spaces, punctuation, and repeated characters are treated as ordinary text rather than patterns, so symbols do not need regular-expression escaping. If the same substring occurs several times, only the first position is reported. That behavior is particularly useful for validation, where the main questions are whether an expected marker appears and where parsing could begin. An empty substring is rejected because every string technically contains it, which would provide a surprising and unhelpful validation result.

Choose whether letter case matters

The case_sensitive option defaults to true. In that mode, uppercase and lowercase letters must match exactly: searching for “Ready” does not match “ready.” Exact matching is appropriate for identifiers, protocol markers, product codes, and any content where capitalization carries meaning. Set the option to false when you want a practical text check that treats those variants alike, such as finding a status word in user-entered notes or checking whether a heading contains a phrase. Case-insensitive mode normalizes both the source text and requested substring consistently before locating the first occurrence, while the reported position still refers to the original text. The capability does not trim either value or alter punctuation, so leading spaces and punctuation remain meaningful. It also does not perform accent folding, stemming, transliteration, fuzzy comparison, or whole-word detection. For example, a search for “cat” can match the first three letters of “catalog.” Keeping these rules narrow makes every result repeatable and prevents a simple contains check from silently making linguistic assumptions that would be unsuitable for identifiers or automated gates.

Use the position safely in validation workflows

A typical workflow sends a candidate value, checks contains, and branches without having to interpret the numeric field. When a match exists, position can support diagnostics, previews, or a later parsing step. For example, an import check can confirm that a header includes a required token and record where it begins; a test can verify that generated copy contains an approved phrase; or a support tool can detect a known marker in a pasted log line. Always treat the returned position as a JavaScript string index, measured in UTF-16 code units. For ordinary Latin text this aligns with familiar character counting, but some emoji and less common Unicode symbols occupy two code units. The capability deliberately returns the platform-native index so browser and API executions remain identical and callers can use it directly with JavaScript slicing methods. This is a literal search rather than a security sanitizer or content classifier. Validate structure separately when accepting markup, commands, or other sensitive formats, and use a dedicated parser when boundaries, escaping rules, or multiple matches matter to the decision.