String Case Converter

Identifier casing conventions are language- and ecosystem-specific. Common styles: camelCase (JavaScript variables), PascalCase (classes, types), snake_case (Python, Ruby), kebab-case (URLs, CSS classes), CONSTANT_CASE (environment variables, constants), and Title Case (headings).

Given any input, the converter splits it into words by detecting case boundaries, separators, and digit transitions, then re-joins them in the target style. Round-tripping isn't always lossless because the original separator information is discarded.

Under the hood, the conversion is two-step: tokenize, then format. Tokenization scans for boundaries: uppercase-after-lowercase (camelCase splits), separator characters (-, _, space), and optionally digit-letter boundaries. So 'parseHTMLString' becomes the tokens [parse, HTML, String] or [parse, H, T, M, L, String] depending on whether the tokenizer recognizes acronyms. Formatting then joins tokens with the target separator and applies the target casing. CONSTANT_CASE uppercases everything; camelCase lowercases the first token and capitalizes the rest; kebab-case joins with hyphens. The lossy step is acronyms — most converters lowercase all letters during normalization, so 'HTTPRequest' becomes 'http_request' becomes 'HttpRequest', losing the acronym capitalization. Some style guides (.NET, Google's Java) actually prefer 'Http' for consistency, sidestepping the issue.

A worked example. Input: 'getUserHTTPResponse_v2'. Tokenization (without acronym awareness): [get, User, H, T, T, P, Response, v, 2]. With acronym awareness: [get, User, HTTP, Response, v2]. Output styles for the second tokenization: camelCase=getUserHttpResponseV2, PascalCase=GetUserHttpResponseV2, snake_case=get_user_http_response_v2, kebab-case=get-user-http-response-v2, CONSTANT_CASE=GET_USER_HTTP_RESPONSE_V2, Title Case='Get User HTTP Response V2'. Title Case typically preserves the acronym in caps; programmer-style cases lowercase it.

Limitations and edge cases. Numbers in the middle of tokens cause splits in some converters and not others. 'iso8601' tokenizes as [iso, 8601] or [iso8601] depending on settings — the first lets you write ISO_8601 and ISO-8601 cleanly, the second produces iso8601 across all styles. Languages where casing matters semantically include Go (initial caps mean exported/public, lowercase means package-private) and Python (single-underscore prefix is a soft 'protected', double underscore triggers name mangling). Casing in those languages isn't just style — it changes program behavior or visibility, and bulk-converting code from one convention to another can silently change exports. Apply with care and a code review pass.