Case Converter
Convert headings and identifiers into 13 case styles with per-line scope, acronym rules and accent folding for filenames or slugs before reuse.{{ values.selected_output }}
| Case | Output | Characters | Best fit | Copy |
|---|---|---|---|---|
| {{ row.label }}Selected | {{ row.output }} | {{ row.characters.toLocaleString() }} | {{ row.use }} |
| Convention | Example | Use when | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.example }} | {{ row.use }} |
The same words can appear as a heading, a variable, a database field, a filename, or a URL path. Each destination has its own case convention. Spaces may become underscores or hyphens, word initials may change, and acronyms may need to follow a project rule.
Display case and identifier case deserve different checks. Sentence case and title case preserve readable punctuation and spacing. camelCase, snake_case, CONSTANT_CASE, and similar identifier forms first find word boundaries and then join the tokens with a fixed capitalization and separator rule.
- Word boundary
- The point between tokens such as
customer,Profile,URL, and2, even when the source has no spaces. - Acronym policy
- The choice to preserve an all-capital token such as
APIor normalize it to the destination's usual capitalization. - Accent folding
- The removal of combining accent marks to make code-oriented output more ASCII-friendly, such as changing
cafétocafe.
Automatic conversion cannot know every naming rule. It cannot identify reserved words, maximum identifier lengths, product spellings, routing constraints, or the preferred treatment of an acronym in a particular codebase. A converted name is a consistent draft that still needs a destination check.
Language adds another limit. Unicode characters have case mappings, but those mappings are not a substitute for locale-aware editing. Public names and prose should be reviewed by someone who understands the language, especially where dotted and dotless letters or other language-specific casing rules matter.
How to Use This Tool:
Choose the convention required by the destination, then check the converted text against that destination's naming rules.
- Paste or load text into Source text, then select the main Target case.
- Use Whole source for one continuous name or phrase. Choose Each line when headings, filenames, routes, or fields must stay on separate lines.
- Set Title policy for Title Case and choose whether source acronyms are normalized or preserved. These choices can change names such as
APIClient. - Turn on Fold accents for code cases only when the destination expects ASCII-oriented keys, classes, filenames, or slugs. Slug output always folds accents.
- Read Converted text and compare a few alternatives in the Variant ledger before renaming files or identifiers in bulk.
Interpreting Results:
The selected output reflects the chosen token, acronym, title, line-scope, accent, and final-newline rules. Character count can change because separators are removed or inserted, accents are folded, or a trailing newline is added.
Check the actual identifier or filename, not only the visual shape. A plausible conversion may still conflict with a linter, database schema, filesystem, router, API contract, or established product name.
Technical Details:
Case conversion begins by deciding whether the source is prose or a token sequence. Lowercase and uppercase apply direct character case mapping. Sentence and title modes preserve the source separators, while code-oriented modes split the source into Unicode letter-and-number tokens and join those tokens again.
Transformation Core:
Code-oriented conversion follows a deterministic path from hidden boundaries to destination-specific joining.
- Optionally decompose accented characters and remove combining accent marks.
- Insert boundaries between acronym and ordinary-capital transitions, lowercase-to-uppercase transitions, and letter-to-number transitions in either direction.
- Remove apostrophes and treat underscores, hyphens, periods, slashes, backslashes, and colons as separators.
- Collect Unicode letters and numbers, apply the acronym policy, then join tokens with the selected capitalization and separator rule.
| Output family | Input example | Result |
|---|---|---|
| camelCase | Quarterly Revenue API v2 | quarterlyRevenueApiV2 |
| PascalCase | Quarterly Revenue API v2 | QuarterlyRevenueApiV2 |
| snake_case | Quarterly Revenue API v2 | quarterly_revenue_api_v_2 |
| CONSTANT_CASE | Quarterly Revenue API v2 | QUARTERLY_REVENUE_API_V_2 |
| kebab-case or url-slug | Quarterly Revenue API v2 | quarterly-revenue-api-v-2 |
Title Case can lowercase minor words such as “and,” “of,” and “the” when they are not the first or last word. Capitalized Case always starts every word with an uppercase letter. Sentence case restarts capitalization after a period, exclamation mark, question mark, or line break.
Input must contain at least one token and may be no longer than 200,000 characters. With whole-source scope, line breaks remain part of prose conversion but code-oriented formats can combine tokens across lines. Per-line scope converts each nonblank line independently and preserves blank line positions. The optional final newline is appended after conversion.
Privacy Notes:
Text conversion runs in the browser and does not require a server request with the source text. Review sensitive filenames, identifiers, and pasted data before copying the result into another application or sharing an exported file.
Worked Examples:
Separate route names
The two-line source Customer Profile URL and Quarterly Report 2026 should become two routes. With Each line and url-slug, the lines remain separate as customer-profile-url and quarterly-report-2026. Whole-source scope would join both lines into one slug.
References:
- Character Properties, Case Mappings & Names FAQ, Unicode Consortium.
- PEP 8 – Style Guide for Python Code, Python Software Foundation.