Question 1

What is the difference between camelCase, PascalCase, and snake_case?

Accepted Answer

camelCase starts with a lowercase letter and capitalizes each new word (myVariableName) — used for JavaScript variables and function parameters. PascalCase capitalizes every word including the first (MyClassName) — used for class names, React components, and TypeScript types. snake_case separates words with underscores, all lowercase (my_variable_name) — the standard in Python, Ruby, and most databases. kebab-case uses hyphens (my-variable-name) — required in CSS classes, HTML attributes, and URL slugs. SCREAMING_SNAKE_CASE is all-caps with underscores (MY_CONSTANT) — for environment variables and constants. Each language and tool enforces its own convention, and mixing them is the most common source of inconsistency in codebases.

Question 2

Which naming convention should I use for JavaScript variables?

Accepted Answer

JavaScript uses camelCase for variables, function parameters, and function names by convention (ECMAScript style guide): const userName, function getData(). PascalCase is reserved for classes and constructor functions: class UserProfile. Constants that are truly immutable and known at build time use SCREAMING_SNAKE_CASE: const MAX_RETRIES = 5. CSS class names and HTML attributes use kebab-case: .user-profile, data-user-id. React component names must be PascalCase because JSX uses the case to distinguish components from DOM elements. This tool converts between all of these instantly so you can paste from one context into another without manual editing.

Question 3

Is the case converter private and free to use?

Accepted Answer

Yes — completely free and completely private. All conversion happens in your browser with JavaScript. Your input never leaves your device: there is no upload, no server call, no analytics tracking of your text, and no account required. You can verify this yourself: disconnect your network after loading the page and the converter still works. This matters for developers pasting proprietary code, internal API names, or client identifiers that should not be transmitted anywhere.

Question 4

How does the converter handle acronyms and edge cases like userID?

Accepted Answer

The converter uses a word-boundary tokenizer that understands three input patterns: camelCase boundaries (userID → user + ID), separator-based input (user_id, user-id, user id), and acronym runs (HTTPServer → HTTP + Server). Acronym handling is configurable via the Acronyms option: with it on, all-caps runs are treated as single words (userID stays userID in camelCase); with it off, they are split (userID → userI + D, which is usually wrong). For most cases the default heuristic — split on case transitions and separators, preserve all-caps runs — produces the expected result. Numbers are kept as part of the preceding word (user2name stays user2name).

camelCase	JavaScript variables, function parameters, JSON keys (myVariableName). The default for JS/TS code outside of classes and components.
PascalCase	Class names, React/Vue/Svelte component names, TypeScript types & interfaces (UserProfileCard). JSX requires PascalCase so components are distinguishable from DOM elements.
snake_case	Python variables & functions, Ruby, most SQL column & table names, database fields (user_profile_id). The PEP 8 standard for Python.
kebab-case	CSS class names, HTML attributes (data-user-id), URL slugs, file names (my-component.js). The only case CSS allows with multiple words.
SCREAMING_SNAKE_CASE	Environment variables, build-time constants (MAX_RETRY_COUNT), Docker env config, .env keys. Conventionally reserved for values known before runtime.
Title Case	Human-readable labels, headings, UI text (User Profile Settings). Not for code — for copy that describes what the code does.

Case Converter

Which case should you use? A practical decision table

Acronyms, numbers, and edge cases — the honest details

Frequently asked questions