Case Converter

A name changes jobs when it moves from a sentence into a heading, filename, database column, JavaScript property, CSS class, or URL path. The words may stay the same, but the expected shape changes: spaces may disappear, separators may appear, and some letters may need uppercase because the destination treats the text as an identifier rather than ordinary prose.

The useful distinction is not just uppercase versus lowercase. Display formats such as sentence case and title case help people read labels and headings. Identifier formats such as camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, dot.case, and slugs help software split, compare, route, or sort names consistently. A good conversion keeps the destination convention visible without pretending that one style fits every codebase or content system.

The hardest part is finding the word boundaries. Natural language usually gives you spaces and punctuation. Code names can hide those boundaries inside customerProfileURL, customer_profile_url, or customer-profile-url. Product names, initialisms, version numbers, apostrophes, and accented letters all need a quick review because a mechanically reasonable split can still be wrong for the project.

International text adds another caution. Unicode defines lowercase, uppercase, and titlecase mappings, but case conversion is not the same as language-aware editing or case folding for search. Characters such as dotted and dotless I, sharp S, ligatures, and letters with accents can behave differently across languages and systems. Public copy should preserve the spelling readers expect. Machine-oriented names need a deliberate choice about when ASCII-friendly output is worth losing accents.

A converted name is best treated as a draft. It removes repetitive reshaping work, but it cannot know reserved words, maximum field length, router behavior, database naming rules, or whether an acronym should stay as URL, become Url, or be written out.

How to Use This Tool:

Pick the destination format first, then check one representative line before copying a large batch.

1. Paste content into Source text, drop plain text into the editor, or browse for one TXT, MD, CSV, JSON, or LOG file under 2 MB. The summary updates with input and output character counts after text is loaded.
2. Choose Target case for the main output. Converted Text shows that selected result, while Case Variant Ledger shows all 13 supported variants for comparison.
3. Set Conversion scope to Each line separately for lists of field names, filenames, headings, paths, or labels. Use Whole source as one phrase when line breaks should become one combined identifier.
4. Open Advanced when title style, acronyms, or accented characters matter. Headline title case keeps short joining words lowercase inside a title except at the beginning or end, while Capitalize every word starts every token uppercase.
5. Use Acronym policy to choose between normalized mixed-case output and preserved all-caps source tokens. This changes outputs such as camelCase, PascalCase, Train-Case, and title-style text more than separator-only lowercase formats.
6. Use Fold accents for code cases when filenames, keys, CSS-friendly names, or slugs need ASCII-oriented words. Plain lower, upper, sentence, and title outputs keep the original letters.
7. If the status says the file type is unsupported, the file is larger than 2 MB, or the browser could not read it, paste a smaller text sample and recheck the token split in the ledger.

After the selected result looks right, copy or download the converted text. Use the ledger or JSON view when you need to compare variants or keep an audit of the active options.

Interpreting Results:

Converted Text is the value produced by the selected target case. Case Variant Ledger is the safer review view because it shows the same source as display text, mixed-case identifiers, separator-based identifiers, and a URL-oriented slug.

A correct-looking conversion can still be wrong for the destination. Check leading digits, reserved words, maximum length, allowed punctuation, Unicode rules, and the naming convention already used nearby. The converter changes word shape; the target system decides validity.

• If one output contains too many words, add spaces or separators to the source so the token split is clear.
• If a list turns into one long value, switch Conversion scope to Each line separately.
• If API becomes Api but the project expects all caps, change Acronym policy and compare the mixed-case variants again.
• If accented letters must survive, avoid slug output and turn off accent folding for code-style cases where the destination permits Unicode.
• If punctuation has meaning, review display-style results closely; punctuation is preserved more in prose formats than in code-style joins.

Technical Details:

Case conversion has two separate jobs: mapping letter case and rebuilding word boundaries. Letter case changes characters to lowercase, uppercase, sentence-style capitals, or title-style capitals. Word-boundary conversion takes recognized word and number tokens, then joins them with no separator, underscores, hyphens, dots, or another destination pattern.

Tokenization matters most for identifier formats. Runs of Unicode letters and numbers are treated as tokens, with extra breaks inserted around common mixed-identifier boundaries such as lowercase-to-uppercase changes, acronym-to-word transitions, and letter-to-digit changes. Underscores, hyphens, dots, slashes, backslashes, and colons act as word separators for code-style outputs. Apostrophes are removed in those code-style joins, which is useful for compact identifiers but may need review for names and titles.

Transformation Core

The main mechanism is a token sequence: normalize word boundaries, collect word and number tokens, apply the requested case policy, and join the tokens with the target pattern. In line scope, the same sequence runs independently for each non-empty line, while blank lines stay blank.

Headline title case uses a small set of minor words: a, an, and, as, at, but, by, for, from, in, into, nor, of, on, or, per, the, to, via, vs, and with. Those words stay lowercase only when they are inside the title, not at the first or last token.

Boundary and Policy Checks

The process is deterministic for the same input and options. For fair comparisons, keep the same conversion scope, title style, acronym policy, accent-fold setting, and target case. Changing any of those options can alter token count, separators, output length, and whether an acronym stays visibly uppercase.

Case conversion does not validate a name against a language, framework, database, router, or filesystem. That final validity check depends on the destination's rules for reserved words, first characters, separators, length, Unicode support, and case sensitivity.

Advanced Tips:

• Switch Conversion scope to Each line separately before converting field lists, route lists, or filenames. Whole-source scope is better for turning a multi-line phrase into one combined identifier.
• Use Case Variant Ledger to compare related forms before choosing one. It is easier to catch a bad token split when camelCase, snake_case, kebab-case, and url-slug are visible together.
• Choose Keep source acronyms uppercase only when the destination convention expects it. Mixed-case codebases often prefer ApiUrl, while some teams require APIURL or APIUrl in selected positions.
• Leave accent folding off for display text and names when the spelling matters. Turn it on for ASCII-oriented code cases only when the destination rejects or discourages accented characters.
• Use JSON or the ledger export when a batch rename needs review later. The recorded target case and active options make it clear which assumptions produced each variant.

Privacy Notes:

The conversion work runs in the browser for pasted text, dropped text, and supported text-like files. Copying and downloading use local browser actions. Treat the editor like any other browser page on a shared machine: clear sensitive text before leaving and avoid loading files you do not intend to review in that session.

• Accepted file types are TXT, MD, CSV, JSON, and LOG, with a 2 MB limit.
• Only the first file is loaded when multiple files are dropped; extra files are ignored.
• Large pasted input can pause the browser while every case variant refreshes.

Worked Examples:

API field list. A source with two lines, Customer profile and URL value, should use Each line separately when the goal is two database or API fields. With snake_case, Converted Text shows customer_profile and url_value on separate lines. Whole-source scope would merge them into one longer identifier.

Acronym convention check. Quarterly Revenue Forecast API v2 in camelCase becomes quarterlyRevenueForecastApiV2 when acronyms are normalized. With source acronyms preserved, later acronym tokens can stay uppercase, so review the ledger before copying a value into a codebase that has a strict convention.

Slug cleanup. A title such as Café menu updates can become cafe-menu-updates with url-slug. That output is lowercase, hyphen joined, and accent folded, which matches common URL readability guidance. If the visible title should keep the accent, use a prose-style case for display text and keep the slug separate.

File recovery. If a dropped spreadsheet or document is rejected, the status asks for TXT, MD, CSV, JSON, or LOG instead. Open the file elsewhere, paste the relevant plain text, and check Case Variant Ledger before exporting a CSV, DOCX, or JSON record.

FAQ:

Glossary:

Token

A word or number segment extracted from the source before joining.

camelCase

A no-separator identifier form with a lowercase first token and capitalized later tokens.

PascalCase

A no-separator identifier form where every token starts uppercase.

snake_case

Lowercase tokens joined by underscores.

kebab-case

Lowercase tokens joined by hyphens.

url-slug

A lowercase, hyphen-joined value intended for readable URL path segments.

Acronym policy

The option that decides whether all-caps source tokens stay uppercase in mixed-case outputs.

Accent folding

Removal of combining accent marks so code-style outputs stay more ASCII-oriented.

References:

• Character Properties, Case Mappings & Names FAQ, Unicode Consortium.
• Camel case, MDN Web Docs, July 11, 2025.
• Kebab case, MDN Web Docs, July 11, 2025.
• PEP 8 - Style Guide for Python Code, Python Software Foundation.
• URL Structure Best Practices for Google Search, Google Search Central.