Case Converter: UPPERCASE, lowercase, Capitalize, camelCase and More
Naming style looks like a matter of taste until it breaks a build. A CI job fails only on Linux, an API silently changes userName to user_name, and a config payload grows by tens of kilobytes on a round trip between two systems. Those failures share one root cause: case and word-boundary conventions that differ between the places a name travels through.
This guide skips the mechanics of the eight conversion modes and takes an engineering view instead. Where each naming style actually came from, which convention belongs in which setting, how case sensitivity turns into production outages, how casing behaves outside English, and how to move one identifier between styles without corrupting it.
1. Where Each Naming Style Came From
Naming styles are not aesthetics. They are sediment left by history and by what each language's grammar allows.
camelCase and PascalCase grew out of C, where identifiers cannot contain spaces and leading underscores were reserved for the standard library. Java formalised the split — PascalCase for types, camelCase for methods and variables — and the convention travelled with the Java ecosystem into JavaScript, C#, Swift and TypeScript.
snake_case comes from the C standard library, where multi-word function names were written with underscores, and was inherited by the scripting languages that followed. Python's PEP 8 names snake_case as the style for functions and variables, and Ruby followed. It is also the SQL convention by default, since SQL is case-insensitive and generally will not accept a hyphen inside an identifier at all.
SCREAMING_SNAKE_CASE survives as the constant style, and as the environment-variable style on Unix, where it provides a visual signal that a value does not change.
kebab-case is the exception that proves the rule about grammar. It is impossible inside code identifiers because user-name parses as "variable user minus variable name" nearly everywhere. So it migrated to the places where no parser is subtracting anything: CSS properties and class names, HTML attributes, URL paths, and npm package names. The tool in front of you writes it as the hyphen style for exactly that reason.
It is also worth remembering a style that lost. Hungarian notation was designed to encode a value's type in its name (strName) at a time when compilers checked little. Once IDEs and type systems could express the same information in a declaration, the prefix became noise, and almost every modern style guide dropped it.
2. Choosing a Convention by Setting
The decision rule collapses into one sentence: follow the convention of the place the name lives in, and convert only once, explicitly, at the boundary. The table below lists the common settings, their convention, and the mistake that actually shows up in review.
| Setting | Convention | Example | Common mistake |
|---|---|---|---|
| JSON field names | camelCase, or snake_case on Python backends | userName / user_name | Mixing both in one payload, forcing clients to carry two lookup paths |
| Database tables and columns | snake_case, tables often plural | order_items.order_id | Creating MixedCase tables that break when migrated across platforms |
| REST URL paths | kebab-case, all lowercase | /api/user-profiles | Leaving capitals in the path, creating cache and route-matching ambiguity |
| Query parameters | Usually aligned with the JSON fields | ?pageSize=20 | snake_case parameters with camelCase response bodies, so the docs drift |
| CSS class names | kebab-case | card-header-title | camelCase classes that clash with the rest of the stylesheet |
| Source file names | Ecosystem-dependent: PascalCase for components, kebab-case for modules | UserCard.tsx / http-client.ts | Ignoring file-system case rules, so builds fail on one platform only |
| Environment variables | SCREAMING_SNAKE_CASE | DATABASE_URL | camelCase names that some shells will not export at all |
| Git branch names | kebab-case | fix/login-timeout | Two machines creating the same branch with different casing |
The first two rows deserve the most attention. JSON field style is part of the published contract. Client parsing code, cache keys and log-field queries may all depend on it, so it cannot be changed unilaterally after release. Mature teams configure the naming policy once in the serializer, mapping snake_case storage to camelCase output automatically, rather than converting by hand in each layer. The database row raises the case-sensitivity problem covered in the next section.
3. Case Sensitivity: Works Locally, Breaks on Deploy
Every failure in this family shares one property: it cannot be reproduced on the developer's machine, because that machine's file system ignores case.
File systems. Linux ext4 is strictly case-sensitive, so User.js and user.js are two files. Windows NTFS is case-insensitive by default, and APFS on macOS is case-insensitive unless formatted otherwise. The consequence is that import User from "./user" against a file called User.js works on two of those platforms and fails the moment it reaches a Linux container. That is the entire reason the "import paths must match file names byte for byte" rule exists.
Databases. Whether MySQL table and schema names are case-sensitive is decided by lower_case_table_names. On Linux it defaults to 0, meaning case-sensitive; on Windows and macOS the default is case-insensitive. Create a table called UserOrders on Windows, query it as userorders, and everything works — until the same migration runs on Linux and reports that the table does not exist. Creating tables in all-lowercase snake_case removes the whole class of problem.
HTTP. Header field names are case-insensitive, but that is not permission to be careless. HTTP/2 and HTTP/3 require header field names to be lowercase, so reusing an HTTP/1.1 style Content-Type in a frame is rejected as a protocol error. Meanwhile several header values are case-sensitive: media type parameters, ETag comparison, and bearer tokens all fail validation if a single letter changes.
Git. On a case-insensitive file system, renaming Readme.md to readme.md may be treated as the same path and silently skipped, so the change never reaches the index even though the file looks renamed on disk. Renaming through an intermediate name is more reliable than trusting a forced rename, and it keeps the published commit honest on every platform.
4. When Casing Is Not One-to-One
Unicode case mapping is not a simple flip, and that is the source of international failures. Three cases cover most of them.
Turkish i. Turkish and Azerbaijani map i and I the opposite way round from English: I lowercases to the dotless ı (U+0131), and i uppercases to the dotted İ (U+0130). Without a Turkish locale, I lowercases to a plain i, so a place name such as Istanbul loses the dotted capital it started with. This shows up in the most ordinary code there is: the line that lowercases an email address before storing or comparing it.
German sharp s. ß has no single-character uppercase form, so uppercasing has to expand it into two letters. straße becomes STRASSE and the length grows from 6 to 7. Lowercasing that back gives strasse, a different string from the original, which makes casing an irreversible operation in German. It cannot be used as a normalise-compare-restore step.
Greek final sigma. Lowercase sigma is written σ in the middle of a word and ς at the end, while both uppercase to Σ. Converting uppercase to lowercase therefore requires knowing whether the character sits at a word ending, which no character-by-character mapping can decide on its own.
The shared lesson: treating case conversion as a stateless character substitution is safe only in ASCII. For multilingual text, the correct order is to normalise first (NFC or NFKC), then apply case mapping under the target locale, and only then compare.
5. Title Case Is a House Style, Not a Rule
"Capitalise every word" is only a rough description. The real rules come from style manuals, and the two best-known manuals do not agree.
The classic example is to. Chicago capitalises it when it marks an infinitive, as in "How to Play Chess", while AP lowercases it. For short words such as and, of, the and in, both manuals lean lowercase — unless the word is the first or last word of the title, where both capitalise it again. That is why one article can carry three visibly different headlines at three different publications while all three are technically correct.
Harder than the manual differences are acronyms and brand names. Words with established internal capitals, such as NASA, iPhone and macOS, come out of a mechanical pass as Nasa, Iphone and Macos. The engineering answer is a preserve-list: any token that matches it is copied through untouched. It is also why an automatic title-case pass still deserves a human read before publication.
6. Worked Examples: Moving One Identifier Between Styles
The hard part of style conversion is not the substitution. It is tokenising the source.
Example 1: splitting a run of capitals. Take the input HTTPServer. The intended word list is [http, server]. Break on every lower-to-upper transition and you get HTTPS plus erver. Break on a run of capitals followed by a capital plus lowercase letters, and you get HTTP plus Server. The two rules give different answers, so the order they run in decides whether the output is correct — the capital-run rule has to run first.
| Target style | Result for HTTPServer | Note |
|---|---|---|
| camelCase | httpServer | First word lowercase, later words capitalised |
| PascalCase | HttpServer | First word capitalised too; the original capital run is flattened |
| snake_case | http_server | Separator removed, underscores inserted, all lowercase |
| kebab-case | http-server | Hyphen separated; the style used for packages and URLs |
| SCREAMING_SNAKE_CASE | HTTP_SERVER | Constant style, all uppercase |
Look at the PascalCase row: the original HTTPServer and the converted HttpServer are not the same string. The information that a word was an all-caps acronym is gone, which makes automated conversion one-way. Do not expect a round trip to return the original identifier. The same holds for XMLHttpRequest, which tokenises to [xml, http, request] and converts to camelCase as xmlHttpRequest rather than the string you started with.
Example 2: abbreviation endings. Take userID. There is no capital run to anchor on, only two trailing capitals. The correct word list is [user, id], giving user_id. A naive rule that splits only on lower-to-upper transitions leaves the capitals attached and yields userid, or splits them into single letters. Before trusting an automated conversion on a real codebase, run it against a sample of genuine identifiers and check the abbreviated endings and any token sitting next to a digit.
Example 3: what the style costs in bytes. Style choice also lands in storage and network budgets, because JSON field names are repeated with every record rather than stored once.
| Style | Field fragment | Characters |
|---|---|---|
| camelCase | {"userName":1,"createdAt":2} | 28 |
| snake_case | {"user_name":1,"created_at":2} | 30 |
Two characters per record sounds irrelevant until you multiply. Across a million records the difference reaches the million-character range before any compression, and it repeats on every response the API serves. It is one of the reasons columnar formats and Protobuf, which separate field names from field values, become attractive as data volumes grow.
7. Frequently Asked Questions
- What naming convention should I use for JSON fields?
- camelCase is the JavaScript and REST default, while snake_case stays common where the backend is written in Python or Ruby. The mistake is not the choice but mixing both inside one payload. Pick one, enforce it in the serializer, and document it in the API contract.
- Why do URLs use hyphens instead of underscores?
- Reasons usually cited are that hyphens read as word separators while underscores are often treated as part of the word, and that underscores can be hidden by the text-decoration underline on links. The widely repeated guidance from Google is to use hyphens in URLs. RFC 3986 allows both characters in a path segment, so this is a convention rather than a protocol rule.
- Why does lowercasing Turkish text produce the wrong letters?
- Turkish maps i and I the opposite way round from English: capital I lowercases to the dotless i (U+0131) and lowercase i uppercases to the dotted capital I (U+0130). Without a Turkish locale, I lowercases to plain i, so a name like Istanbul loses its dotted capital letter. Pass the Turkish locale explicitly, or verify dotted and dotless i after converting.
- Is a full file rename safe on a case-insensitive file system?
- Not reliably. On NTFS and on default APFS, renaming Readme.md to readme.md may be treated as the same path and skipped, so the change never reaches the index. Renaming through an intermediate name, or forcing the staged rename, avoids publishing a commit that only looks correct on one platform.
- Why is userID a hard input for a case converter?
- Because there is no run of consecutive capitals to anchor the split. The correct word list is user plus id, giving user_id. A naive rule that only splits on lower-to-upper transitions leaves the trailing capitals attached and produces userid or splits them into separate single letters. Test abbreviated endings before trusting an automated conversion.
8. Four Mistakes Worth Avoiding
Assuming file-name case does not matter because "the system ignores it". Whether it matters is a property of the file system, not the language. NTFS ignores case by default, ext4 does not, and APFS sits in between depending on how the volume was formatted. The same repository can therefore behave differently on three machines, and the difference only surfaces at deployment.
Treating the Turkish problem as an edge case for an edge language. It affects any code path that lowercases input before comparing or storing it: email normalisation, username deduplication, search indexes, URL slug generation. One Turkish user is enough to break the path, and it will often go untested for years.
Equating all caps with emphasis. Capitals flatten the word shapes readers rely on, so long passages slow down noticeably. Some screen readers also spell out runs of capitals letter by letter, turning a word into a string of letters. Emphasis belongs to weight, colour and spacing.
Believing naming style is pure preference and needs no written rule. No style is objectively best, but inconsistency has a measurable cost: two styles side by side break code search, bulk renaming and generated documentation, which are the tools that make a large codebase maintainable at all.
9. Three Practical Recommendations
- Write the naming table into the project docs, and write only one. State which style each layer uses — database, API, frontend, CSS, file names — and who owns the conversion at each boundary. One authoritative table removes the gap where every layer assumes another layer already converted, which is where double and missing conversions both come from. When a converted batch has to land in a structured config file, validate it first with a JSON formatter.
- Always pass the locale explicitly when normalising case. Any code that lowercases user input for comparison or storage should state the locale rather than inherit a runtime default, and the suite should carry two assertions: Turkish I against its lowercase form, and the German sharp s against its uppercase expansion. Those two lines catch most international regressions.
- Do bulk renames and bulk conversions under version control. Convert a batch of field names with the case converter, review the diff with a text diff tool, and commit the whole change in one pass. Half by hand and half by script is the state that is hardest to review. If you are also tracking how much text a rename touches, a word counter confirms the size of the change before you commit it.
A naming convention ships no features, but it decides whether a codebase stays legible to tooling and to the next developer. Fixing it as a written decision once is far cheaper than repairing it with scripts later. For the other class of copy-and-paste failure, the one caused by characters you cannot see, continue with invisible characters and text cleanup.