What happens with umlauts and accented characters?

Accented characters like a, o, u or e stay in the output — only the case changes. If you need a pure ASCII identifier afterwards, run the slug generator next: it transliterates per RFC 3986 to plain ASCII.

How does the tool handle consecutive uppercase letters?

Consecutive uppercase letters are treated as one acronym. XMLParser splits into two tokens (XML + Parser), not four — matching the lodash and Google convention.

Does the tool work offline?

Yes. The entire conversion runs in your browser via JavaScript. No text is sent to our server — not for logging, not for analytics.

Which variant is standard for database columns?

SQL standards are case-insensitive; in practice snake_case dominates (PostgreSQL convention, Rails default). PostgreSQL quoted identifiers preserve camel-case ( "userId" ) but force quoting in every query — generally inconvenient.

What is Title Case vs. Sentence case?

Title Case capitalizes every word ("How To Convert Text"). Sentence case capitalizes only the first word ("How to convert text"). The Chicago Manual of Style recommends Title Case for headings, with exceptions for articles/prepositions under five letters.

Can I share a conversion via URL?

Yes, the entered text is automatically encoded into the URL as ?data=... parameter (up to 1000 chars). When the recipient opens the link, they see the exact same result instantly.

Case Converter

Convert instantly into 14 formats

Why different cases?

Every programming language has its conventions: JavaScript uses camelCase for variables and PascalCase for classes, Python and Ruby prefer snake_case, CSS and URLs need kebab-case, constants are typically SCREAMING_SNAKE_CASE. This tool swaps between all common conventions in one click — no manual retyping.

Where is each case used?

camelCase: JavaScript variables, JSON properties, Java/C# methods
PascalCase: classes in C#, TypeScript, Java; React components
snake_case: Python, Ruby, Rust variables, SQL column names
kebab-case: CSS classes, URLs/slugs, HTML data- attributes

Tokenization: how a case converter detects words

Before text gets converted to another case, it must be split into individual words. That sounds trivial but is actually the hardest part of the tool. Inputs like parseHTMLString, getURL2API or kebab-case_mixed.example mix camel boundaries, acronyms, separators and digits all at once. A robust algorithm works in three passes: first split at aA transitions (lower-to-upper), then at acronym boundaries like HTMLParser becoming HTML plus Parser, finally split on every separator like _, -, . and /. The Unicode UAX #29 specification (Text Segmentation) formally describes this as word-boundary detection.

Acronyms are the most common pitfall. Naive conversion of XMLHttpRequest to snake_case produces x_m_l_http_request — functionally correct but unreadable. Most libraries (lodash, change-case, Google Java Style Guide) recommend treating multi-letter acronyms as a single word. That gives xml_http_request and XmlHttpRequest instead of XMLHTTPRequest. Google amended its style guide in 2017 to use parseHtml() instead of parseHTML(). Anyone refactoring old code should know this rule — otherwise subtle diff conflicts emerge during reviews.

Digits create ambiguity too. Should iPad2Pro become i_pad_2_pro, i_pad2_pro or i_pad2pro? Rust's convention (RFC 430) is to keep digits glued to the previous token (i_pad2_pro), while Microsoft .NET treats them as standalone components. We follow the Rust convention because it is more compact and produces fewer conflicts with domain-specific identifiers like HTML5, ES2024 or UTF8. Teams should pin this rule in their style guide — it prevents future renames that show up as the only change in pull requests. Another often-overlooked trap is reserved words: convert class to PascalCase and you get Class, which is an invalid identifier in C#, Java or Python. Style guides recommend either a suffix (UserClass) or a prefix (cls_user) — the converter can't catch this automatically because the reserved-word list is language-specific.

Step by step: convert identifiers cleanly

For larger refactorings, a systematic workflow prevents missed cases:

Paste source code or identifier list into the field — e.g. old_user_id, oldUserId, OLD_USER_ID.
Pick target format: camelCase for JS/Java, snake_case for Python/SQL, kebab-case for CSS/URLs.
Verify result: acronyms like HTTP, ID, URL now appear as single words (http/Http).
Copy via the button and run find-and-replace in your IDE — one variant per search.
Run tests: dynamically built properties (e.g. obj["old_user_id"]) are not auto-renamed by IDE refactorings.

Real-world examples from everyday code

These typical conversions show how the tool handles mixed input:

getUserById → snake_case → get_user_by_id (Python function).
background-color → camelCase → backgroundColor (CSS property in JS DOM).
MAX_RETRY_ATTEMPTS → PascalCase → MaxRetryAttempts (C# constant renamed to enum member).
parseXMLDocument → kebab-case → parse-xml-document (acronym kept as single token).
order.items[0].productId → snake_case (per segment) → order.items[0].product_id.

Limits: where the converter (intentionally) won't help

The converter is a text tool, not a refactoring tool. It does not understand scope: let userId inside a function can safely become user_id, but once the variable becomes a JSON property going out the wire, the API changes. It also cannot recognize domain acronyms: iOSAppId may mean iOS-App-Id in one context and i-os-app-id in another — the algorithm must pick one. For mass refactorings in production code always use jscodeshift, ast-grep or your IDE's rename-refactoring which knows the symbol graph. The converter is ideal for one-offs, database schemas, CSS-to-JS property maps and style-guide migrations. Another point: for languages with accented characters like French or Spanish, the converter cannot decide whether Cafe becomes CAFE or CAFE (accent preserved) — we keep the accent. Unicode normalization (NFC vs. NFD) is a separate topic that often produces undetected duplicates in file and database imports.

Frequently asked questions

What happens with umlauts and accented characters?: Accented characters like a, o, u or e stay in the output — only the case changes. If you need a pure ASCII identifier afterwards, run the slug generator next: it transliterates per RFC 3986 to plain ASCII.
How does the tool handle consecutive uppercase letters?: Consecutive uppercase letters are treated as one acronym. XMLParser splits into two tokens (XML + Parser), not four — matching the lodash and Google convention.
Does the tool work offline?: Yes. The entire conversion runs in your browser via JavaScript. No text is sent to our server — not for logging, not for analytics.
Which variant is standard for database columns?: SQL standards are case-insensitive; in practice snake_case dominates (PostgreSQL convention, Rails default). PostgreSQL quoted identifiers preserve camel-case ("userId") but force quoting in every query — generally inconvenient.
What is Title Case vs. Sentence case?: Title Case capitalizes every word ("How To Convert Text"). Sentence case capitalizes only the first word ("How to convert text"). The Chicago Manual of Style recommends Title Case for headings, with exceptions for articles/prepositions under five letters.
Can I share a conversion via URL?: Yes, the entered text is automatically encoded into the URL as ?data=... parameter (up to 1000 chars). When the recipient opens the link, they see the exact same result instantly.