Skip to main content
Utility Tools

Text Case Converter

Convert text between UPPER, lower, Title, camelCase, snake_case, and more.

No upload — your files never leave your device

  • 100% private
  • Runs in your browser
  • Works offline
  • No sign-up
43 chars·9 words·1 lines

Basic

Code

Fun

About Text Case

Text Case converts a string between every naming convention a developer or writer hits in a normal week — camelCase, PascalCase, snake_case, SCREAMING_SNAKE, kebab-case, dot.case, Title Case, Sentence case, lowercase and UPPERCASE. It detects word boundaries intelligently: a string like 'XMLHttpRequest' splits into XML, Http, Request the way you'd expect rather than treating runs of capitals as a single token. Useful for renaming variables across languages, normalising spreadsheet headers, and turning prose into URL slugs.

  • No uploads
  • Browser-only
  • Works offline
  • 100% free

How it works

  1. 1

    Paste your text

    Drop in one string or several lines — each line is converted independently so you can bulk-rename a whole list of identifiers at once.

  2. 2

    See every case at once

    Every supported case appears in its own row with a copy button. There's no mode to pick — you see all conversions simultaneously and copy the one you need.

  3. 3

    Copy with one click

    Click any row to copy that variant. The original input stays in the source box so you can keep tweaking it without losing your starting point.

The case conventions, and where each belongs

Changing case sounds like a one-line job until you realize how many distinct conventions exist and how loaded each one is with meaning. UPPERCASE, lowercase and Title Case are for prose and headings. The programming cases — camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE — are not stylistic; they're conventions that signal intent to other developers and, in some languages, are enforced by tooling. Converting between them is a routine task when you're moving an identifier from a database column to a JavaScript variable, or turning a heading into a URL slug.

The mechanical part is splitting a string into words; the convention just decides how to glue them back together. "user profile ID" becomes userProfileId (camel), UserProfileId (Pascal), user_profile_id (snake), user-profile-id (kebab), or USER_PROFILE_ID (constant). The hard part is the edge cases.

Which convention goes where

CaseLooks likeConventional home
camelCaseuserProfileIdJavaScript/Java variables and functions
PascalCaseUserProfileIdClass and type names; React components
snake_caseuser_profile_idPython, Ruby, SQL columns, database fields
kebab-caseuser-profile-idURLs, CSS classes, HTML attributes, filenames
CONSTANT_CASEUSER_PROFILE_IDConstants, environment variables, enum values
Title CaseUser Profile IdHeadings, titles, button labels

These are conventions, not laws — but violating the one a language expects makes code read as foreign to everyone else on the team.

The locale trap: Turkish i and friends

Case conversion is not as universal as it looks, because letter case is language-dependent. The textbook example is Turkish and Azeri: those languages have a dotless lowercase i and a dotted uppercase I, so uppercasing and lowercasing behave the opposite of English. Code that uppercases an identifier or a hostname using the user's locale instead of an invariant rule has caused real, hard-to-trace bugs (the infamous "Turkish-I problem"). The Unicode case-mapping rules document this in detail at unicode.org.

The practical takeaway: for human-facing text, locale-aware casing is correct. For identifiers, code, and protocol strings — anything a machine compares — you want invariant, locale-independent casing so "FILE" lowercases to "file" everywhere on Earth. German eszett (which traditionally uppercases to "SS," changing the string length) and accented characters are smaller versions of the same lesson: casing can change length and is not always reversible.

What case conversion won't fix

  • It doesn't validate identifiers. Converting "123 widgets" to camelCase gives "123Widgets," which is an illegal variable name in most languages — leading digits and reserved words still need a human eye.
  • Round-tripping isn't guaranteed. Going to kebab-case and back can't always restore the original word boundaries: "APIKey" to snake might become "a_p_i_key" or "api_key" depending on how acronyms are detected.
  • Acronyms are genuinely ambiguous. Is "getHTTPResponse" three words or four? Different converters disagree, so review output that contains initialisms.
  • If your real goal is cleaning stray whitespace or smart quotes rather than re-casing, use Text Clean; to count the result against a length limit, Word Count.

Frequently asked questions about Text Case

  • How are word boundaries detected?

    We split on three signals: whitespace, common separators (- _ . / etc.), and transitions inside camelCase or PascalCase. The transition rule handles the awkward case of consecutive capitals: 'parseHTML5Doc' splits as parse, HTML5, Doc rather than parse, H, T, M, L, 5, Doc. Numbers are kept attached to the preceding word by default.

  • What's the difference between Title Case and Sentence case?

    Title Case capitalises every word (with optional small-word exceptions for of, the, and, etc.). Sentence case capitalises only the first letter of the whole string. Both are intended for prose — for identifiers you almost always want PascalCase or camelCase instead.

  • Does it handle non-ASCII input like accents or CJK?

    Yes for accented Latin scripts (é, ñ, ü are preserved through case conversion using full Unicode case mapping). CJK and other non-cased scripts are passed through unchanged — there's no concept of upper/lowercase in Chinese, Japanese kana, or Korean Hangul, so the case is the original character.

Privacy, offline use, browser support, and pricing questions are answered on the site-wide FAQ.

See all Text tools