String Case Converter

Why Naming Conventions Matter in Programming

Naming conventions are one of the most fundamental aspects of writing clean, maintainable code. A consistent naming style makes code easier to read, reduces cognitive load during code reviews, and helps teams collaborate more effectively. When every variable, function, class, and file follows a predictable pattern, developers can instantly recognize what an identifier represents without deciphering its structure.

Beyond readability, naming conventions carry semantic meaning. In many languages and frameworks, the case style of an identifier signals its role: a SCREAMING_SNAKE_CASE constant in Python communicates immutability, while a PascalCase name in JavaScript signals a class or React component. Breaking these conventions can confuse other developers and even break tooling that relies on naming patterns.

A Guide to Every Case Style

camelCase

In camelCase, the first word is lowercase and every subsequent word starts with a capital letter: myVariableName, getUserById, isActive. This is the dominant convention for local variables, function names, and object properties in JavaScript, TypeScript, Java, C# (for parameters and local variables), and Swift. It is also the standard for JSON keys in most REST APIs.

PascalCase (UpperCamelCase)

PascalCase is identical to camelCase except the first letter is also capitalized: MyClassName, UserProfile, HttpRequest. It is the standard for class names in virtually every object-oriented language. In Go, PascalCase has a special meaning — exported (public) identifiers must start with an uppercase letter. In React, component names must be PascalCase to distinguish them from HTML elements. C# uses PascalCase for method names, properties, and public members.

snake_case

Words are separated by underscores, all lowercase: my_variable_name, get_user_by_id, is_active. This is the standard convention in Python (PEP 8), Ruby, Rust, PHP, and Elixir for variables, functions, and module names. It is also common in SQL for column and table names, and in C for function and variable identifiers.

SCREAMING_SNAKE_CASE (UPPER_SNAKE_CASE)

All uppercase with underscores: MAX_RETRY_COUNT, API_BASE_URL, DEFAULT_TIMEOUT. This is the universal convention for constants across nearly every language: Python, Java, JavaScript, C, C++, Rust, Go, and more. Environment variables also follow this convention (DATABASE_URL, NODE_ENV). In Rust, enum variants use SCREAMING_SNAKE_CASE in some codebases, though PascalCase is more common.

kebab-case

Words separated by hyphens, all lowercase: my-component-name, font-size, background-color. This is the standard in CSS for property names and class names, in HTML for attributes and custom data attributes (data-user-id), and for URL slugs (/blog/my-first-post). Many frontend frameworks use kebab-case for component file names. It is also the convention for npm package names and CLI command flags.

SCREAMING-KEBAB-CASE (UPPER-KEBAB)

All uppercase with hyphens: CONTENT-TYPE, X-REQUEST-ID, ACCEPT-ENCODING. This style is seen in HTTP headers (though headers are technically case-insensitive) and occasionally in configuration keys. It is less common in source code but important when working with web standards and network protocols.

dot.case

Words separated by dots, all lowercase: com.example.myapp, server.port, spring.datasource.url. This convention is standard for Java package names, configuration files (Spring Boot’s application.properties, Gradle properties), and JavaScript object access paths (lodash.get(obj, "user.address.city")).

path/case

Words separated by forward slashes, all lowercase: components/user/profile, api/v2/users. This mirrors file system paths and URL structures. It is useful when converting identifier names into directory paths or route patterns, particularly in frameworks that use file-system based routing like Next.js.

Title Case

Every word starts with a capital letter, separated by spaces: My Variable Name, User Profile Settings. This is the convention for headings, UI labels, and documentation titles. Style guides differ on whether minor words like “the,” “and,” and “of” should be capitalized, but for code-related conversions, capitalizing every word is the standard approach.

Sentence case

Only the first word is capitalized: My variable name, User profile settings. This is standard for user-facing text, error messages, tooltips, and form labels in many UI design systems. Google’s Material Design and Apple’s Human Interface Guidelines both recommend sentence case for most UI strings.

Naming Conventions by Language and Framework

Each programming language and framework has its own established conventions. Using the wrong case style can make your code look out of place and confuse collaborators. Here is a comprehensive reference:

• JavaScript / TypeScript — camelCase for variables and functions, PascalCase for classes and React components, SCREAMING_SNAKE_CASE for constants.
• Python — snake_case for variables, functions, and methods (PEP 8). PascalCase for classes. SCREAMING_SNAKE_CASE for constants. Module names are lowercase with underscores.
• Java — camelCase for variables and methods, PascalCase for classes and interfaces, SCREAMING_SNAKE_CASE for constants. Package names use dot.case (all lowercase).
• Go — PascalCase for exported (public) identifiers, camelCase for unexported (private) ones. Acronyms are kept fully uppercase (HTTPClient, not HttpClient).
• Rust — snake_case for variables, functions, and modules. PascalCase for types, traits, and enum variants. SCREAMING_SNAKE_CASE for constants and statics.
• C# / .NET — PascalCase for public members, methods, properties, and classes. camelCase for local variables and parameters. Many teams prefix private fields with an underscore (_fieldName).
• Ruby — snake_case for methods and variables. PascalCase (CamelCase) for classes and modules. SCREAMING_SNAKE_CASE for constants.
• CSS — kebab-case for properties, class names, and custom properties (--primary-color).
• SQL — SCREAMING_SNAKE_CASE for keywords (convention), snake_case for table and column names. Some teams use PascalCase for table names.
• PHP — camelCase for methods, PascalCase for classes, snake_case for functions (in legacy code and WordPress), SCREAMING_SNAKE_CASE for constants.

Case Conventions in APIs and JSON

One of the most common pain points in full-stack development is the mismatch between backend and frontend naming conventions. A Python backend sends user_name (snake_case), but the JavaScript frontend expects userName (camelCase). This requires conversion at the API boundary.

Most modern REST APIs standardize on camelCase for JSON keys, following the conventions established by Google’s API Design Guide and the JSON:API specification. However, many APIs built with Python (Django REST Framework, Flask) or Ruby (Rails) default to snake_case. GraphQL APIs almost universally use camelCase.

To handle these mismatches, developers typically write serialization middleware or use libraries like humps (JavaScript), djangorestframework-camel-case (Python), or olive_branch (Ruby) that automatically convert between case styles at the API boundary.

Case Conversion in Code Refactoring

Renaming variables, functions, or files to match a different naming convention is a common refactoring task. This happens when migrating codebases, enforcing new style guides, or integrating with third-party libraries that use a different convention. Manual conversion is tedious and error-prone, especially when dealing with acronyms (XMLHTTPRequest → xml_http_request) or numbers embedded in identifiers (getUser2FA → get_user_2_fa).

This tool handles these edge cases automatically. The smart word detection algorithm splits input by recognizing camelCase boundaries ( lowercase-to-uppercase transitions), consecutive uppercase sequences (HTML stays together when followed by a lowercase letter), number-to-letter boundaries, and common delimiters (spaces, hyphens, underscores, dots, slashes). This makes it reliable for converting even complex real-world identifiers.

Style Guides and Linting Rules

Modern development teams enforce naming conventions through style guides and automated linting. Here are the most influential style guides and their naming rules:

• Google Style Guides — Google publishes style guides for C++, Java, Python, JavaScript, TypeScript, Go, and more. Each specifies exact naming conventions. The Google Java Style Guide, for example, requires camelCase for non-constant field names and SCREAMING_SNAKE_CASE for constants.
• Airbnb JavaScript Style Guide — One of the most widely adopted JavaScript style guides. Requires camelCase for variables and functions, PascalCase for classes and React components, and SCREAMING_SNAKE_CASE for exported constants.
• PEP 8 (Python) — The official Python style guide. Mandates snake_case for functions, methods, and variables. PascalCase for classes. SCREAMING_SNAKE_CASE for constants.
• Rust API Guidelines — Enforced by the clippy linter. snake_case for functions and variables, PascalCase for types, SCREAMING_SNAKE_CASE for constants.

Tools like ESLint (@typescript-eslint/naming-convention), Pylint, RuboCop, and Clippy can automatically flag naming convention violations. Integrating these linters into your CI/CD pipeline ensures consistent naming across the entire codebase.

How This Tool Works

This string case converter runs entirely in your browser. Your input never leaves your device. The conversion algorithm works in two steps:

1. Word detection: The input is split into individual words using a smart algorithm that recognizes camelCase boundaries (myVar → ["my", "Var"]), consecutive uppercase letters (HTMLParser → ["HTML", "Parser"]), number boundaries (myVar2Name → ["my", "Var", "2", "Name"]), and common delimiters (spaces, hyphens, underscores, dots, slashes).
2. Conversion: The detected words are reassembled using the rules of each target case style. All 12 conversions are computed simultaneously and displayed in real-time as you type.

Frequently Asked Questions

What is the difference between camelCase and PascalCase?

Both styles capitalize the first letter of each word except in camelCase, the very first letter is lowercase (myVariable), while in PascalCase the first letter is also uppercase (MyVariable). PascalCase is sometimes called “UpperCamelCase.” In practice, camelCase is used for variables and functions, while PascalCase is reserved for classes, types, and components.

Why do different languages use different naming conventions?

Naming conventions evolved with each language’s community and culture. Python’s snake_case was formalized in PEP 8 (2001) and reflects the language’s emphasis on readability. Java’s camelCase was established by Sun Microsystems in the original Java coding conventions (1997). Go’s use of capitalization for visibility (exported vs. unexported) is a language design decision that makes the convention mandatory rather than optional.

How does the tool handle acronyms like HTML or API?

The smart word detection algorithm recognizes consecutive uppercase letters as a single word when followed by a lowercase letter. For example, HTMLParser is split into ["HTML", "Parser"], and getAPIResponse becomes ["get", "API", "Response"]. This produces correct results like html_parser and get-api-response.

Can I convert multi-line text?

The tool is designed for single identifier conversion. If you paste multi-line text, it will treat the entire input as one identifier and split it into words. For best results, convert one variable or identifier name at a time.

Is this tool safe for sensitive code?

Yes. All processing happens locally in your browser using pure JavaScript. No data is transmitted to any server. You can verify this by monitoring the Network tab in your browser’s developer tools while using the converter.