Detect text case style

This case detector examines the exact characters you provide and reports whether they follow camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, Train-Case, dot.case, path/case, Title Case, Sentence case, or a simple upper- or lowercase form. It performs strict, deterministic matching, so the same input always receives the same result and ambiguous or irregular text is clearly marked as mixed.

Understand what the detector checks

The detector compares your complete input with a defined set of naming patterns. It does not merely count capitals or look for one separator. For camelCase, the text must begin with lowercase letters and contain at least one capitalized word boundary. PascalCase begins with a capital and joins subsequent words without separators. Snake, constant, kebab, dot, and path styles require at least two nonempty segments separated consistently by underscores, hyphens, periods, or forward slashes. Space-separated text is checked for Title Case, Sentence case, lowercase words, and uppercase words. A successful result includes the recognized style and a short reason. If punctuation, inconsistent separators, unexpected capitals, or surrounding whitespace prevents an exact match, the result is mixed instead of making a misleading guess. This strict behavior is especially useful in validation because it distinguishes a convention that is actually followed from text that only resembles it. Digits are accepted within many identifier segments, while empty input and non-string values are rejected as invalid input rather than classified.

Use exact detection for convention validation

A style label becomes most useful when it is part of a repeatable quality check. Send an identifier from a form, data pipeline, code generator, or naming audit and compare the returned style with the convention your project expects. For example, an API field policy may require snake_case, while a JavaScript property policy may require camelCase. A mixed result tells you that the input needs review, but the detector deliberately does not rewrite it. Keeping detection separate from conversion prevents an automated check from silently changing public names, database columns, or keys that may already be referenced elsewhere. The response also includes a recognized boolean, which makes branching straightforward: accepted named conventions return true, while irregular text returns false. Exact matching means leading and trailing whitespace matters; this catches invisible copy-and-paste problems before identifiers enter a system. When you need to process many values, call the capability once per item and store both the original value and detected style in your validation report. That creates an auditable result and lets a human decide whether exceptional names are intentional.

Interpret boundaries and ambiguous inputs

Case names can overlap when an input contains only one word, so this detector uses practical precedence and avoids claiming word boundaries that are not present. A single lowercase token is reported as lowercase, not camelCase, because camel case normally demonstrates at least one joined capitalized segment. Likewise, one uppercase token is UPPERCASE rather than CONSTANT_CASE. Multiword separated forms are more specific: customer_order_id is snake_case, CUSTOMER_ORDER_ID is CONSTANT_CASE, and Customer Order Id is Title Case. Sentence case requires an initial capital followed by lowercase space-separated words, while Title Case requires each word to begin with a capital. Acronym-heavy strings, Unicode letters, apostrophes, commas, doubled separators, and combinations such as snake-Case are returned as mixed when they do not exactly fit a supported pattern. That conservative outcome is intentional: guessing a familiar label could allow a malformed identifier through a validator. The algorithm is local and analytic, with no network requests, language model, randomness, or time-dependent behavior. Browser checks are available on the page, and API automation costs $0.002 per item.