Case Converter
Convert text between camelCase, PascalCase, snake_case, kebab-case and more — all at once, entirely in your browser.
- Runs in your browser
- No upload, no tracking
- Free forever
—————————How it works
A case converter transforms text between programming naming conventions — camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE, Title Case and more — by detecting word boundaries and re-joining the words in the target style. It is useful for renaming variables, database columns, API fields and CSS classes consistently. This tool runs entirely client-side and is built by JusDB, a managed database operations team, for the everyday string work around schemas and code.
- 1
Paste your text
Type or paste any words or identifiers into the input box — single or multi-line. Use Load sample to see it in action.
- 2
Read every case at once
Each naming convention is rendered live in its own card as you type — camelCase, snake_case, kebab-case, CONSTANT_CASE, Title Case and the rest.
- 3
Convert line by line
Multi-line input is converted one line at a time, preserving your line breaks so you can transform a whole list of names in one pass.
- 4
Copy what you need
Click the copy icon on any case card to send just that format to your clipboard. Nothing is ever uploaded.
Frequently asked questions
- What case formats are supported?
- The tool converts to camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE, lowercase, UPPERCASE, Title Case, and Sentence case — all at once.
- How does the converter detect word boundaries?
- It splits on spaces, hyphens, underscores, and transitions between lowercase and uppercase letters (for camelCase/PascalCase inputs). This means any input format is correctly tokenized.
- Does it support multi-line input?
- Yes. Each line is converted independently, preserving your line breaks in the output.
- Is any data sent to a server?
- No. All conversion is performed with pure JavaScript running in your browser. Nothing is transmitted to JusDB or anywhere else, so it is safe to convert identifiers from production code.
- What is the difference between snake_case and CONSTANT_CASE?
- Both join words with underscores, but snake_case is all lowercase (user_id) while CONSTANT_CASE is all uppercase (USER_ID). snake_case is common for SQL columns and Python variables; CONSTANT_CASE is conventionally used for constants and environment variables.
- Does it preserve numbers and acronyms?
- Numbers are kept and treated as part of the adjacent word. Acronyms are normalised to the target case, so an input like "HTTPServer" becomes httpServer in camelCase rather than preserving the original capitalisation.
Choosing the right case for code, databases and URLs
Every ecosystem settled on its own naming convention, and switching between them by hand is where typos creep in. Knowing which case is idiomatic where — and how those choices interact with database identifiers — lets you rename a field once and apply it cleanly across your schema, your models and your front end.
Where each case style is conventional
camelCase is the default for variables and methods in JavaScript, TypeScript, Java and Kotlin (firstName, getUserById). PascalCase — the same style with a leading capital — names classes, types, React components and C# members (UserAccount, OrderService). snake_case dominates Python and Ruby for variables and functions (first_name, save_record), and is also the prevailing style for SQL columns and table names. kebab-case suits things that live in text where underscores are awkward or invalid: CSS classes, HTML attributes, npm package names and URL slugs (user-profile, /case-converter). SCREAMING_SNAKE_CASE marks compile-time constants and environment variables (MAX_RETRIES, DATABASE_URL), signalling "do not reassign". Title Case is for prose and headings rather than identifiers. Picking the locally idiomatic style matters less for correctness than for readability — code that follows the conventions of its language reads as if it belongs there.
The database angle: identifiers and case-folding
SQL gives case conversion real teeth. The community convention is snake_case for tables and columns (created_at, customer_id), partly because of how engines fold case. In PostgreSQL, an unquoted identifier is silently lowercased — so CREATE TABLE Users actually creates a table named users, and SELECT firstName resolves to firstname. The moment you wrap an identifier in double quotes ("firstName"), Postgres treats it as case-sensitive and you must quote it everywhere thereafter, forever. Sticking to lowercase snake_case sidesteps that trap entirely. ORMs then bridge the gap: tools like Prisma, ActiveRecord and SQLAlchemy map a snake_case column (user_id) to a camelCase or PascalCase property in your application model (userId), so the database stays idiomatic for SQL while your code stays idiomatic for its language. Converting a column list to camelCase in bulk is exactly the kind of chore this tool removes.
The acronym edge case
Acronyms are where well-meaning conversions disagree. Should an HTTP status type be HTTPStatus or HttpStatus? Should an identifier read userID or userId? There is no universal answer: Microsoft's .NET guidelines say treat acronyms longer than two letters as a single capitalised word (HttpStatus, XmlParser), while plenty of Java and Go code preserves the full uppercase run (HTTPStatus, ID). The practical risk is a round trip — converting HTTPServer to snake_case and back may yield HttpServer rather than the original. This tool normalises acronyms to the target case rather than preserving their original capitalisation, so pick the spelling your linter enforces and apply it consistently across the codebase rather than mixing styles.
Renaming an identifier across a schema? Convert the column once here, then generate a migration. Pair this with the UUID generator when you need stable primary keys to go with your freshly named columns.