How to use
Paste any identifier — `userId`, `user_id`, `user-id`, `USER_ID`, even `user id` — and all nine case variants populate at once. The tokenizer first splits the input on camelCase boundaries (`userId` → `user`, `Id`) and explicit separators (`- _ . /` and whitespace), then re-joins the tokens in whichever style you copy from. Consecutive uppercase letters are kept together as one token, so `HTTPRequest` becomes `http` + `request` rather than `h`, `t`, `t`, `p`, `request`.
Reach for this when crossing language conventions: renaming a Python `snake_case` variable into JavaScript `camelCase`, generating a TypeScript type name (`PascalCase`) from a database column (`snake_case`), turning a constant (`MAX_RETRIES`) into a CSS variable (`max-retries`), or producing a URL slug from a heading. The tool runs in the browser; long lists of identifiers process instantly because the tokenizer is a single regex pass.
Examples
Cross between language conventions
Input
user_profile_image_url
Output
camelCase: userProfileImageUrl
PascalCase: UserProfileImageUrl
snake_case: user_profile_image_url
kebab-case: user-profile-image-url
CONSTANT_CASE: USER_PROFILE_IMAGE_URL
Title Case: User Profile Image Url
A Python `snake_case` field name maps cleanly to JavaScript `camelCase` (`userProfileImageUrl`), CSS variable `kebab-case` (`--user-profile-image-url`), or a TypeScript type `PascalCase` (`UserProfileImageUrl`). The Title Case form loses the URL convention (`Url` instead of `URL`); see the next example for the acronym case.
Handling acronyms
Output
camelCase: httpRequestHandler
PascalCase: HttpRequestHandler
snake_case: http_request_handler
kebab-case: http-request-handler
Consecutive uppercase letters group as one token, so `HTTPRequestHandler` tokenizes to `http`, `request`, `handler` rather than letter-by-letter. The output flattens acronyms to lowercase (Java / TypeScript convention). If your style guide requires preserved acronyms (`HTTPRequestHandler` in Go) the tool won't produce that — Go advocates the `MixedCaps` style with all-caps acronyms but treats it as a community preference, not a syntactic requirement.
A sentence becomes a URL slug
Input
Why your AWS bill suddenly spikes
Output
kebab-case: why-your-aws-bill-suddenly-spikes
snake_case: why_your_aws_bill_suddenly_spikes
kebab-case is the convention for URL paths, CSS classes, npm package names, and shell command names — anywhere case-sensitivity is unreliable. For URL slugs you also want to drop punctuation and lowercase — this tool covers the casing; for full slug rules (punctuation strip, accent removal, max length) use the URL Slug tool.
FAQ
How does the tokenizer know where words start?
Two rules. First, an explicit separator (`-`, `_`, `.`, `/`, or whitespace) ends a token. Second, a case transition signals a boundary: lowercase or digit followed by uppercase (`userId` → `user|Id`), or run of uppercase followed by uppercase-then-lowercase (`HTTPRequest` → `HTTP|Request`). Combined, these cover the common identifier styles. Non-ASCII letters do not transition by case so Korean or Japanese text inside an identifier stays as a single token.
Which case should I pick for which language?
Conventions are well-settled. **JavaScript / TypeScript**: variables and functions camelCase, types and components PascalCase, constants UPPER_SNAKE. **Python**: variables and functions snake_case, classes PascalCase, constants UPPER_SNAKE. **Rust**: variables and functions snake_case, types and traits PascalCase, constants UPPER_SNAKE. **Go**: exported names `MixedCaps`, unexported `mixedCaps` (camelCase), no underscores. **CSS / HTML attributes**: kebab-case. **SQL / PostgreSQL**: snake_case for tables and columns. **shell scripts**: lowercase or kebab-case file names, UPPER for env vars.
My acronym got lowercased — `URL` became `Url`. Can I keep it?
Not from this tool — every variant lowercases tokens before re-joining. Acronym preservation requires a token-level decision (is this token an acronym?) which depends on context, not the input. For Go where the style guide demands `HTTPRequest`, write it as that source by hand or use an editor command. For Java / TypeScript where `HttpRequest` is preferred, this tool already matches.
What about identifiers with digits like `apiV2`?
`apiV2` tokenizes as `api`, `v2` because the case transition between lowercase `i` and uppercase `V` marks a boundary. The digit `2` stays attached to the `v` token, so `snake_case` produces `api_v2` not `api_v_2`. If you want the digit as its own token (`api_v_2`), insert an explicit separator (`apiV-2`) before pasting.
Does it handle Korean / Japanese / Chinese characters?
They pass through as a single token because CJK characters have no case to transition. `사용자ID` tokenizes as `사용자`, `id` (the Korean part is one token, the Latin acronym is split off by the case rule). For mixed-script identifiers this works reasonably well; for pure CJK input the casings other than snake / kebab look identical (joining `\사용자`, `\이름` with `_` versus a dash).
Can I convert multiple identifiers at once?
The tool treats the input as a single identifier, so a multi-line paste becomes one giant token sequence with line breaks acting as separators. For a real batch — converting every column name in a SQL table to camelCase — pipe through `awk` or a sed command instead, or use an editor multi-cursor selection. The web tool is built for one identifier at a time, fast.
Related concepts
Identifier case styles encode word boundaries without spaces, which programming languages mostly cannot use inside names. Five styles dominate. **camelCase** lowercases the first word and capitalizes the rest — JavaScript, Java, C# methods. **PascalCase** capitalizes every word — type names across most languages, .NET methods, React components. **snake_case** lowercases and joins with underscores — Python, Ruby, Rust, SQL columns. **kebab-case** does the same with hyphens — CSS, URLs, shell commands. **CONSTANT_CASE** (or SCREAMING_SNAKE) uppercases everything joined by underscores — global constants, environment variables, preprocessor macros.
The choice is almost entirely cultural, not technical. Languages permit multiple styles syntactically and rely on community style guides — PEP 8 for Python, Effective Go, Rust API Guidelines, Airbnb JavaScript Style Guide. Picking a style that matches the surrounding ecosystem keeps code grep-friendly, IDE autocomplete sensible, and code review focused on logic instead of bikeshedding. Mixing styles within a project is the actual mistake; the choice between styles matters less than picking one and sticking with it.
Two edge cases catch teams off guard. **Acronyms** split the community: Java / TypeScript prefer `HttpRequest`, Go prefers `HTTPRequest`, Microsoft .NET goes both ways depending on length (`HtmlParser` but `IO`). Whichever you pick, document the rule explicitly so reviewers do not relitigate it weekly. **Database column ↔ application property** mapping is the second hot spot — `user_profile_image_url` in PostgreSQL becomes `userProfileImageUrl` in a TypeScript model, requiring a deterministic case-conversion layer. ORMs like Prisma, SQLAlchemy, and TypeORM build this into their schema definitions; rolling it by hand is where this tool earns its keep.
