BRev camelCase converter
camelCase joins words with no separator and capitalises every word except the first: parseXmlFile, userId, getElementById. The lowercase first letter is the whole distinction from PascalCase, and in several languages it is not a style preference but a semantic marker — it says “this is a variable or a method”, not a type.
It is the default identifier style across most of the industry: JavaScript and TypeScript variables and functions, Java methods and fields, C# locals and parameters, Swift, Kotlin, and the key names in the overwhelming majority of JSON APIs. Where a language ships a formatter or a linter, the rule is usually enforced rather than suggested.
The interesting question is what happens to acronyms, and there is no universal answer — which is why this converter makes it a toggle instead of picking for you. Convert with acronym preservation on and XML stays XML; turn it off and you get parseXmlFile, which is what most style guides now recommend precisely because it round-trips predictably.
camelCase — worked through
Every line below is produced by the same converter that runs on this page, so the example and the tool cannot disagree.
| Input | camelCase | Note |
|---|---|---|
| parse xml file | parseXmlFile | The canonical shape of this style. |
| parse the XML file from the ERP API | parseTheXMLFileFromTheErpAPI | Acronym preservation on — the converter’s default. |
| parse the XML file from the ERP API | parseTheXmlFileFromTheErpApi | Acronym list off — the “treat acronyms as ordinary words” convention. |
Where camelCase is the convention
| Ecosystem | What it applies to |
|---|---|
JavaScript / TypeScript | Variables, functions and object properties. The DOM and standard library are camelCase throughout (getElementById, addEventListener), so anything else reads as foreign. |
Java | Methods and fields, per the language’s original conventions — PascalCase is reserved for types, so the case difference carries meaning to a reader. |
C# | Locals, parameters and private fields. Public members are PascalCase, which is why C# code mixes the two deliberately within one class. |
JSON APIs | The dominant key style, largely because JavaScript consumes it directly. Go and Python servers map to it with struct tags and serialiser aliases rather than renaming their own fields. |
The acronym trap
parseXMLFile or parseXmlFile? Both appear in real code. Treating an acronym as a single word (parseXmlFile) is what Google’s Java style guide, the .NET guidelines and most modern linters recommend, because XMLHTTPRequest has no readable word boundaries and because it converts back to the original words without ambiguity. Preserving the acronym (parseXMLFile) reads better to people who know the term and is common in older Java and Objective-C. Pick one and enforce it — the damage comes from a codebase that does both.
مرحبا بالعالم. The Unicode slug keeps the original script.FAQ
What is the difference between camelCase and PascalCase?
Only the first letter. camelCase starts lowercase (userName), PascalCase starts uppercase (UserName). In Java, C# and Go that difference is meaningful — it distinguishes a variable from a type, or in Go an unexported identifier from an exported one.
Should acronyms be capitalised in camelCase?
Modern guidance says treat them as ordinary words — parseXmlFile, not parseXMLFile — because it is unambiguous and reversible. Older code often preserves them. The rule that matters is consistency within a codebase.
Why is camelCase used for JSON keys?
Because JavaScript reads them as property names directly, so a camelCase key becomes idiomatic JS with no translation. Servers in other languages map their own conventions onto it at the serialisation boundary instead.