camelCase, snake_case, and kebab-case Converter

Case conversion rewrites identifiers between styles: camelCase, PascalCase, snake_case, SCREAMING_SNAKE, and kebab-case. The words stay the same; separators and capitalization change. Teams hit this when bridging JSON APIs, SQL columns, and CSS class names.

Style cheat sheet

Style	Example	Common home
camelCase	userId	JavaScript
PascalCase	UserId	Types / components
snake_case	user_id	Python, SQL
kebab-case	user-id	CSS, URLs

Rules of thumb

1. Do not case-convert user-visible prose the same way — only identifiers.
2. Acronyms (HTTPServer) need team conventions (httpServer vs HTTPServer).
3. Round-tripping can lose information if the original had irregular caps.
4. Bulk-convert API samples before writing mapping layers.

Use TryDevSnip

TryDevSnip Case Converter switches casing in the browser. Combine with Word Counter for docs, or Text Diff to verify a rename pass.

Privacy one-liner: conversion runs on your device; not uploaded to our servers for processing.

Mapping layers beat ad-hoc renames

In production code, convert at the boundary: read snake_case from the API, map once to camelCase for the UI, and write back with the same mapper. Spreadsheet-style case conversion is for samples, docs, and one-off migrations — not for renaming symbols across a live codebase without tests.

FAQ

Should JSON APIs use camelCase or snake_case?

Either — pick one per API and stick to it. Many public JSON APIs use camelCase; many backends store snake_case.

Is kebab-case valid in JavaScript variables?

Not without quotes — user-id is minus, not a name. Use camelCase in JS, kebab in CSS.

Can I convert a whole file safely?

Automated renames can break strings and comments. Prefer IDE renames for symbols; use converters for lists and samples.

What about Title Case?

Useful for headings, not code identifiers. Keep it separate from programming-case tools.