Case
Converter

camelCase (userId, fetchUserData) is the JavaScript and TypeScript convention for variables and functions. It is also standard in Java, Swift, Kotlin, and most modern OO languages for local variables and methods.

snake_case (user_id, fetch_user_data) dominates Python (PEP 8), Ruby, Rust, and SQL. It is also the de-facto JSON convention for APIs designed against Python or Rails backends. Snake case wins on long identifiers because underscores create natural word breaks.

kebab-case (user-id, fetch-user-data) is the URL slug convention, the CSS class and custom-property convention, and the HTML attribute convention. It is invalid as an identifier in almost every programming language because the hyphen parses as subtraction.

PascalCase (UserId, FetchUserData) marks types and classes in most languages: classes in JavaScript/TypeScript/Python/Java/C#, structs in Rust and Go (exported only), components in React. CONSTANT_CASE (MAX_RETRIES) is universal for compile-time constants, environment variables, and configuration keys.

ToolSeo.case-converter.section1.p5

Go uses case as visibility: identifiers starting with an uppercase letter are exported (public); lowercase are package-private. User and user are not just style choices — they change the language semantics. This is unique to Go among major languages.

Ruby uses snake_case for methods and variables, PascalCase for classes and modules, and SCREAMING_SNAKE for constants. Rust enforces the same conventions with compiler warnings: non_snake_case and non_upper_case_globals lints fire on style violations.

JSON conventions are not standardized but de-facto split by ecosystem: REST APIs from Python/Rails backends use snake_case keys; APIs from Node/Java backends use camelCase; some legacy Microsoft APIs use PascalCase. Keep a single convention per API and document it.

CSS uses kebab-case for properties (background-color), custom properties (--brand-primary), and class names by convention (.product-card, BEM .product-card__title--featured). HTML uses kebab-case for custom data attributes (data-user-id) but reserves camelCase for ARIA properties accessed in JavaScript (el.dataset.userId).

ToolSeo.case-converter.section2.p5

Acronyms are the hardest part of case conversion. Should XMLHttpRequest become x_m_l_http_request or xml_http_request? The latter is what most modern style guides recommend. Google's JavaScript style guide says treat acronyms as a single word in camelCase: parseHtml, not parseHTML. The .NET style guide says the opposite for two-letter acronyms: IOStream is fine, but HtmlParser for longer ones. ConverterUp follows the Google convention by default and offers a 'preserve acronyms' toggle.

Numbers are also ambiguous. Does html5Parser split as html5 + Parser (digits stick to the preceding word) or html + 5Parser? The default is digits-stick-to-preceding, producing snake_case html5_parser. For SemVer-style identifiers, this matters: oauth2Client should become oauth2_client, not oauth_2_client.

Word boundaries on already-mixed input are detected at: lowercase-to-uppercase transitions (fooBar → foo, Bar), uppercase-acronym-to-PascalCase transitions (HTMLParser → HTML, Parser), digit transitions when 'split on digit' is enabled, and explicit separators (-, _, ., space). When converting a mix of conventions, paste once, normalize to a known intermediate (often kebab-case), then convert to the target.

ToolSeo.case-converter.section3.p4

ToolSeo.case-converter.section3.p5

ToolSeo.case-converter.section4.p1

ToolSeo.case-converter.section4.p2

ToolSeo.case-converter.section4.p3

ToolSeo.case-converter.section4.p4

ToolSeo.case-converter.section4.p5

ToolSeo.case-converter.section5.p1

ToolSeo.case-converter.section5.p2

ToolSeo.case-converter.section5.p3

ToolSeo.case-converter.section5.p4

ToolSeo.case-converter.section5.p5