Text & everyday tools · Text Toolkit
camelCase, snake_case, kebab-case and PascalCase: where each is used
· Background
case-conversion identifiers developer-workflow
A tour of the naming conventions — where they came from, which languages and ecosystems expect which, and why file names, URLs, database columns and JSON keys each pull in a different direction.
Five names for one thing — userProfileId, user_profile_id, user-profile-id, UserProfileId and USER_PROFILE_ID
The phrase "user profile ID" can become `userProfileId`, `UserProfileId`, `user_profile_id`, or `user-profile-id` without changing its words. The visible difference is where boundaries appear and whether the first word begins with a capital. ToolAcre generates those four forms directly from the same input, making their structural differences easy to compare.
An all-uppercase `USER_PROFILE_ID` is another useful project convention, but it is not a separate combined option in the case converter source. The toolkit exposes snake case and uppercase transformations independently. If a codebase uses uppercase constants, convert to snake case and then uppercase it rather than claiming the case menu performs both steps at once.
Four conversions demonstrated by the Text Toolkit, plus an uppercase constant form assembled separately
`camelCase` starts with a lowercase word and capitalizes the start of every following word. `PascalCase` applies the same joined-word shape while capitalizing the first word too. In ToolAcre, both transformations begin with the same word splitter, so punctuation and existing case boundaries are interpreted before the output is assembled.
Many teams assign the two forms to different kinds of names, but the repository does not establish a universal language rule or a history for that split. Treat a local style guide, linter, framework API, or nearby code as the authority. The converter changes spelling shape; it does not determine whether a name represents a class, function, variable, or component.
camelCase and PascalCase differ by the first letter; their language history is outside repository evidence
`snake_case` lowers every detected word and joins the results with underscores. For `User Profile ID`, ToolAcre returns `user_profile_id`. The separators remain visible, which can help when names pass through systems that do not preserve capitalization reliably, but that practical benefit is not proof that every database, language, or service expects underscores.
Use the convention already defined at the destination. A Python service may have one policy, an SQL schema another, and a serialized payload a third. ToolAcre cannot inspect those contracts. Its reliable promise is narrower: `toSnakeCase` detects words, lowercases each one, and inserts `_` between them without deciding whether the destination permits or prefers that result.
snake_case output is supported directly; ecosystem and SQL expectations depend on each project
`kebab-case` uses the same lowercase words but joins them with hyphens, producing `user-profile-id`. That shape is visually clear in places where a hyphen is accepted as data, such as a configured route segment or a project-defined filename. It is not a JavaScript identifier because the parser can read a hyphen as an operator rather than part of one name.
The outline lists CSS classes, HTML attributes, command-line flags, and URL slugs, yet the text library does not define the rules of those consumers. Confirm the target syntax before converting. ToolAcre also has a separate `slugify` function with accent folding, separator selection, trimming, and optional length handling, so ordinary kebab conversion should not be presented as full URL-slug validation.
kebab-case output is supported directly; valid uses depend on the surrounding syntax
Boundaries are where naming conventions become operational rather than cosmetic. A browser object can use one spelling while an API payload or database column uses another. Make that mapping explicit at one adapter instead of scattering conversions across views, queries, and business logic. A predictable edge keeps each internal model consistent and makes mismatches easier to locate.
Avoid converting arbitrary values merely because they look like identifiers. The word splitter treats punctuation as boundaries and recognizes selected transitions between lowercase, uppercase, and digits. That is useful for names, but it can alter keys whose spelling is externally fixed. Preserve contract keys exactly unless the receiving interface documents a mapping under your control.
Worked example — converting one identifier through all the conventions and deciding which belongs where in a small project
Consider a small application with the phrase `user profile ID`. ToolAcre produces `userProfileId` for camel case, `UserProfileId` for Pascal case, `user_profile_id` for snake case, and `user-profile-id` for kebab case. Each output carries the same three detected words, while capitalization and the inserted separator encode the selected shape.
A practical project might keep `userProfileId` in a JavaScript object, map it explicitly to `user_profile_id` at a persistence boundary, and reserve `user-profile-id` for a location whose grammar accepts hyphens. The exact choices belong to that project. The important part is documenting each boundary and testing the mapping instead of repeatedly guessing from appearance.
What this does not cover — Hungarian notation and the debates about abbreviations inside identifiers
This comparison does not settle abbreviation spelling. The implementation turns detected words into lowercase pieces before rebuilding them, so an input containing `HTTP` may emerge as `Http` inside Pascal or camel output. Whether a team prefers `Http`, `HTTP`, `Id`, or `ID` is a naming policy that needs an explicit exception outside these general transformations.
It also does not cover notation history, language standards, or every valid identifier grammar. Those claims require sources beyond the tool files used for this article. ToolAcre demonstrates deterministic text transformations and documents one key limitation: a compound written without any detectable boundary cannot always be split into the words a person intended.
Abbreviation policy and notation history are outside the converter evidence
No one case is universally correct. A name is useful when it follows the contract and remains recognizable to the people maintaining that layer. Start with the convention already present, keep one form inside a boundary, and translate only where another interface requires it. Consistency reduces incidental differences without pretending every ecosystem shares one rule.
When a boundary does require another shape, paste the identifier into the Text Toolkit case converter and inspect the four outputs before applying one. The operation runs in the browser and the manifest states that text is not sent to a server or autosaved. Use the result as a deliberate mapping, then let project tests and local style checks confirm the final choice.